View
3
Download
0
Category
Preview:
Citation preview
Remote Accessibility to Diabetes Management and Therapy in
Operational Healthcare Networks
REACTION (FP7 248590)
D4-3 Technical Requirements for Medical
Data Management
Date 2010-08-31
Version 1.2
Dissemination Level: Public
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 2 of 85 DATE 2010-08-31
Table of Contents
1. Executive Summary ................................................................................................................. 5
2. Abbreviations and Acronyms ................................................................................................. 7
3. Introduction .............................................................................................................................. 9
3.1 Overview of the REACTION Project .................................................................................... 9 3.2 Purpose, Context and Scope of this Deliverable ................................................................. 9
4. Software Requirements Engineering ................................................................................... 11
4.1 Definitions and Terminologies ........................................................................................... 11 4.2 Bridging the Gap between User and Technical Requirements ......................................... 12 4.3 Tools for Supporting the Requirement Management ........................................................ 14 4.4 Towards a REACTION Data Model ................................................................................... 17
5. REACTION Platform: Technical Requirements for a Data Management Model .............. 19
5.1 Data Interface .................................................................................................................... 19 5.2 Data Source (with focus on PAN/BAN) ............................................................................. 24 5.3 Data Storage ...................................................................................................................... 28 5.4 Data Structure .................................................................................................................... 34 5.5 Data Semantics ................................................................................................................. 36 5.6 Data Security ..................................................................................................................... 42
6. REACTION Prototypes: Use-Cases for Applications ......................................................... 50
6.1 Inpatient Glucose Control .................................................................................................. 50 6.2 Primary Care Diabetes Management ................................................................................ 64
7. Conclusions ............................................................................................................................ 76
7.1 REACTION Platform .......................................................................................................... 76 7.2 Application Prototypes ....................................................................................................... 78
8. Table of Figures and Tables ................................................................................................. 81
8.1 Figures ............................................................................................................................... 81 8.2 Tables ................................................................................................................................ 81
9. References .............................................................................................................................. 82
10. Appendix I ............................................................................................................................... 83
10.1 Draft Architecture of REACTION Primary Care Diabetes Management Platform .......... 83 10.2 Questions related to Requirement Elicitation Process .................................................... 84
11. Appendix II: Complete set of Technical Requirements for a Medical Data Management Model ................................................................................................................................................. 85
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 3 of 85 DATE 2010-08-31
Document control page
Code D4-3_2010_08_31_Technical_requirements_for_medical_data_management_V12.pdf
Version 1.2
Date 2010-08-31
Dissemination level PU
Category R
Participant Partner(s) FORTH-ICS, FORTHNET, FHG-SIT, ATOS, CNET, ALL, MSG
Author(s) Stephan Spat, Peter Beck, Matthias Enzmann, Matts Ahlsén, Tamás Tóth, Vasilis Kontogiannis, Carlos Cavero Barca, Peter Rosengren
Verified and approved by
Work Package WP4
Fragment No
Distribution List All
Abstract
This deliverable bridges the gap between the functional user requirements and technical system requirements for a REACTION data model. It presents business use-cases for the inpatient and the primary care prototypes identified in the initial user requirements of D2-5. Moreover, this deliverable summarizes technical requirements for the medical data management of the REACTION platform.
Comments and modifications
Status
Draft Task leader accepted WP leader accepted Technical supervisor accepted Medical Engineering supervisor accepted Medical supervisor accepted Quality manager checked Project Coordinator accepted
Action requested
to be revised by partners involved in the preparation of the deliverable for approval of the task leader for approval of the WP leader for approval of the Technical Manager for approval of the Medical Engineering Manager for approval of the Medical Manager for approval of the Quality Manager for approval of the Project Coordinator
Deadline for action:
Keywords data management model, technical requirements, use cases
References
Previous Versions
Version Notes
Version Author(s) Date Changes made
0.4 Stephan Spat 2010-07-19 Initial version
0.5 Stephan Spat 2010-08-05 TOC update, Introduction
0.6 Stephan Spat 2010-08-10 Contribution to chapter 3, 4, 5, 6 and 10
0.7 Stephan Spat, Peter Beck, Matthias Enzmann, Tamás Tóth, Vasilis Kontogiannis, Carlos Cavero Barca
2010-08-13 New TOC based on requirement subtypes; contributions from partners to chapter 5 and chapter 6
0.8 Stephan Spat, Peter Beck, Louise Schmidt
2010-08-16 Update REACTION prototypes (chapter 6); Proofreading
0.9 Stephan Spat, Matts Ahlsén, Peter Rosengren
2010-08-19 Update chapter 4 and 5
1.0 Stephan Spat 2010-08-21 Conclusion and executive summary
1.1 Stephan Spat, Matts Ahlén 2010-08-30 Improvements suggested by reviewers
1.2 Stephan Spat 2010-08-31 Final version submitted to EC
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 4 of 85 DATE 2010-08-31
Internal review history
Reviewed by Date Comments made
Jesper Thestrup, IN-JET 2010-08-25 Improve definition of requirements section, more results in executive summary, improve storage management, stringent focus on requirements and not on design
Franco Chiarugi, FORTH-ICS 2010-08-26 Several acronyms are not listed, improve definition in requirements section, improve conclusion section
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 5 of 85 DATE 2010-08-31
1. Executive Summary
This document continues along the path set by D2-1 and D2-5, which began with the generation of scenarios for usage of the REACTION platform. D2-1 described the requirements, needs and priorities of the users. The short and medium-term expectations for primary care and inpatient care, derived from two workshops in Chorleywood and Graz, were outlined. D2-5 presented the methodology, process and results of the initial requirement analysis and engineering phase of WP2 related to the user centric requirements for engineering and validation. The main results of D2-5 was the generation of approximately 280 initial user requirements which forms the foundation for further work on the REACTION project.
This deliverable is based to a large extent on those initial user requirements and covers the task of analysing the technical requirements for a specific medical data management model for the REACTION platform.
D4-3 is an important initial working point for WP4. The objectives of WP4 are to research, develop and implement the complex Data Management structure of the REACTION platform. Based on the elicited requirements in this work, a suitable architecture for the data fusion/diffusion model in a device and network oriented environment and the technology to implement it in the REACTION platform will be specified. In consequence, this document bridges the gap between the functional user requirements and technical system requirements for a REACTION data model. Moreover, this deliverable presents business use-cases for the inpatient and the primary care prototypes. These use-cases enable technical partners to obtain a better understanding of the main tasks of the REACTION prototypes, including how system components interact with users. The work on this deliverable was carried out in six steps:
(Step 1) Typical business use-cases for inpatient insulin dosing and primary care disease management as well as a draft architecture for the REACTION were generated.
(Step 2) Based on the use-cases and on the draft architecture, an intensive discussion among involved partners was initiated. Suggestions for improvements arising from this discussion were incorporated and the draft architecture and use cases were distributed to involved partners.
(Step 3) Questions concerning system components, which may be interesting in eliciting technical requirements for the REACTION data management model, have been formulated and distributed to involved partners.
(Step 4) In order to define a data management model six different aspects of a data model have been defined: Data Interface, Data Source, Data Storage, Data Structure, Data Semantics, and Data Security.
(Step 5) JIRA has been set up for the elicitation of technical requirements. Each partner was responsible for eliciting technical requirements and resolving conflicting, overlapping, obsolete, or erroneous requirements.
(Step 6) Requirements were stratified by data management model subtypes and the outcome of the requirement elicitation phase was summarized and related to the needs of a REACTION data model as well as of the entire architecture, taking into account that the REACTION pilot applications need further steps of analysis.
There are over 130 technical requirements for a REACTION data management model which have been collected, revised, and analysed for this deliverable. Following conclusions can be drawn from the work:
• REACTION will implement a distributed system. From this it follows that the system architecture needs different interfaces for external and internal interfaces in order to exchange data.
• Several data interfaces will comply with various standards, primarily those intended for eHealth interoperability and communication with medical devices.
• In the REACTION platform patient data is collected from three different sources: (1) measurements from medical devices, (2) manually entered data by the patient or a member of the medical team, and (3) data imported from external source.
• Data storage is necessary in all distributed parts of the REACTION data management architecture: (1) Patient devices, (2) REACTION AHD/Hosting Client, (3) REACTION DEVICE Hosting Server, and (4) Data Mining / Risk Stratification.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 6 of 85 DATE 2010-08-31
• REACTION platform should be flexibly and support various types of disease management applications, i.e. REACTION should support model driven architecture with functions based on formal models and rules.
• REACTION platform needs flexibly data structures in order to consider the model driven architecture.
• REACTION will be based on a service oriented architecture and will be deployed in a distributed manner, i.e. data structures have to be exchanged between components.
• In order to support the semantic management of data and as a basis for knowledge management, REACTION will exploit semantic technologies.
• A medical knowledge base will be built.
• Confidentiality has to be guaranteed in order to allow medical devices to upload measurements.
• Authenticity of senders and recipients of medical data must be ensured.
• Data integrity must be verifiable and the verification must be carried out before the data is added to the EHR.
• Access to personal data will be given to authorised entities only.
• Patient’s consent must be sought before any data processing can take place.
The early stage of the project combined with the ambitious overall aim of the REACTION project that covers wide areas of the treatment of diabetic patients, mean that current elicited user requirements are not as technical as needed to drive the platform design requirements. To alleviate this, D4-3 enables partners to gain a clear understanding of the main use-cases of the prototypes and to consider how technical solutions can help to implement a data management model that provides a sufficient technical basis for fulfilling the requirements of use-cases.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 7 of 85 DATE 2010-08-31
2. Abbreviations and Acronyms
For the purposes of this deliverable, the following abbreviations and acronyms apply.
3G Third Generation (International Mobile Telecommunication-2000)
AHD Application Hosting Device
API Application Programming Interface
BAN Body Area Network
BM Bio Measurement
BMI Body Mass Index
CA Certification Authority
CGM Continuous Glucose Monitoring
DB Database
DoW Description of Work
EAV Entity-Attribute-Value
eDSS Electronic Decision Support System
EHR Electronic Health Record
EPR Electronic Patient Record
GP General Practitioner
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
HbA1c Glycated Haemoglobin
HIS Health Information System
HL7 v2/v3 Health Level 7 Version2/Version3
IEEE Institute of Electrical and Electronics Engineers
IEEE PHD IEEE Personal Health Data
IHE-PCD01 Integrating the Healthcare Enterprise-Patient Care Devices Technical framework version1
IHE-XDS Integrating the Healthcare Enterprise-Cross Enterprise Document Sharing
IP Internet Protocol
ISO International Organization for Standardisation
IT Information Technology
IV Intravenous
JIRA Issue Tracker (Trunction of Gojira, Japanese for Godzilla)
LAN Local Area Network
LIS Laboratory Information System
MS Microsoft
NLP Natural Language Processing
OAD Oral anti-diabetic Drug
OBS Observations
OWL Web Ontology Language
P2P Peer to Peer
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 8 of 85 DATE 2010-08-31
PAN Personal Area Network
PDA Personal Digital Assistant
PEG tube Percutaneous Endoscopic Gastrostomy Tube
PHR Personal Health Record
PID Person Identifier
PII Personally Identifiable Information
POCT Point of Care Testing
QoS Quality of Services
RDMM REACTION Data Management Model Requirements
RPM Remote Patient Monitoring
SC Subcutane
SMS Short Message Service
SNOMED Systematized Nomenclature of Medicine -- Clinical Terms
SoA Service oriented Architecture
SQL Structured Query Language
SRS Software Requirements Specification
TOC Table of Contents
TP Trusted Party
UI User Interface
UML Unified Meta Language
UMLS Unified Medical Language System
WP Work Package
XML Extensible Markup Language
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 9 of 85 DATE 2010-08-31
3. Introduction
3.1 Overview of the REACTION Project
The REACTION project aims to develop an integrated approach to improve long term management of diabetes through continuous blood glucose monitoring, monitoring of significant events, monitoring and predicting risks and/or related disease indicators, evidence-based decisions on therapy and treatments, education on life style factors such as obesity and exercise and, ultimately, automated closed-loop delivery of insulin.
The REACTION project seeks to use the significant potential of new technologies to cope with the increasing number of persons suffering from insulin-dependent diabetes. A user-centred approach will be used, focused on the involvement of all stakeholders (i.e. patients, relatives and professional carers as well as healthcare commissioners, business stakeholders, and regulatory authorities) in an iterative cycle aimed at maximizing the probabilities of success of the new technological platform of services.
Technically, the REACTION platform will be structured as an interoperable peer-to-peer communication platform based on service-oriented architecture (SoA), where all functionalities, including the measurement acquisition performed by sensors and/or devices, are represented as services and applications consist of a series of services properly orchestrated in order to perform a desired workflow. The REACTION platform will, in addition, make extensive use of dynamic ontologies and advanced data management capabilities offering algorithms for clinical assessment and evaluation.
A range of REACTION services will be developed targeted to the management of insulin-dependent diabetic patients in different clinical environments. The services aim to improve continuous blood glucose monitoring (CGM) and insulin therapy by contextualized glycaemic control based on patient activity, nutrition, interfering drugs, stress level, etc. to enable a proper evaluation and adjustments of basal and bolus doses. Decision support will assist healthcare professionals, patients and informal carers to make correct choices about blood glucose control, nutrition, exercise, and insulin dosage, thus ensuring better management of diabetes.
REACTION will further develop complementary services targeted at the long term management of all diabetic patients (Type I and Type II). Integrated monitoring, education, and risk evaluation will ensure all patients remain at healthy and safe blood glucose levels, with early detection of onset of complications.
Security and safety of the proposed services will be studied and necessary solutions to minimize risks and preserve privacy will be implemented. The legal framework for patient safety and liability as well as privacy and ethical concerns will be analyzed and an outline of a policy framework will be defined. Moreover, impacts on health care organizations and structures will be analyzed and health-economics and business models will be developed.
3.2 Purpose, Context and Scope of this Deliverable
This section discusses the main intention of the deliverable. It shows on the work on which this deliverable is based, i.e. D2-1 and D2-5, as well as future work which will be based upon it. Moreover, it outlines the target audience and the scope of the deliverable.
3.2.1 Background and Context
D4-3 “Technical Requirements for Medical Data Management” continues along the path set by D2-1, which began with the generation of scenarios for usage of the REACTION platform. D2-1 described the requirements, needs and priorities of the users. The short and medium-term expectations for primary care and inpatient care, derived from two workshops in Chorleywood and Graz, were outlined. In addition new care models to meet the requirements of possible future developments were described. Scenarios for the long-term requirement, and finally vision scenarios of future healthcare were presented. The main outcomes of D2-1, especially regarding user requirements, were summarized in a structured way in the Initial Requirements Report of D2-5. D2-5 presented the methodology, process and results of the initial requirement analysis and engineering phase of WP2 related to the user centric requirements for engineering and validation. The main results of D2-5 was the generation of approximately 280 initial user requirements which forms the foundation for further work on the REACTION project.
The purpose of T4-3 is the research and development of the software components required to perform the core data management task including data capture, support for contextualization, data fusion,
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 10 of 85 DATE 2010-08-31
inferring of knowledge, and invoking of event handling. D4-3 is, to a large extent, based on the initial user requirements and serves as the basis for future work on T4-3 Data management. D4-3 should provide a good basis for the work in T4-3 as regards user requirements.
3.2.2 Target Audience
The target audience of the deliverable is primarily technically partners, but also ethical, legal and sociological aspects have to be incorporated into the data management model for REACTION. In particular questions concerning data privacy, data security or data availability must be addressed (see in particular section 5.6).
3.2.3 Purpose
D4-3 summarises the technical requirements for a medical data management model for the REACTION platform, based on the user requirements derived in WP2. It is an important foundation for the appropriate architecture of the data fusion/diffusion model in a device and network oriented environment of REACTION. In consequence, D4-3 bridges the gap between the functional user requirements and technical system requirements for a REACTION data model. Moreover, D4-3 presents use-cases for the inpatient and the primary care prototypes identified in the initial user requirements of D2-5. These use-cases enable technical partners to obtain a better understanding of the main tasks of the REACTION prototypes, including how system components interact with users.
3.2.4 Scope
The scope of D4-3 is not restricted to the gathering of requirements of a medical data model for the REACTION platform, but also includes how these requirements correlate with use-cases of the inpatient insulin dosing and the primary care disease management prototypes.
In accordance with D2-5, D4-3 similarly follows the iterative approach for the refinement of requirements in the context of a user-centred design approach. Thus, a change in user-requirements may influence technical requirements for the REACTION data management model. Requirements will be fully managed using appropriate requirement management tools.
D4-3 will cover neither the work on the detailed design of the medical data model nor the detailed architecture of the technical platform of REACTION or its prototypes.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 11 of 85 DATE 2010-08-31
4. Software Requirements Engineering
4.1 Definitions and Terminologies
4.1.1 Requirements
The user-centred approach of REACTION necessitates a structured and well documented strategy in order to perform software requirement engineering. D2-5 established a common understanding of what the requirements are and how the requirement engineering process should be performed. This document builds upon this common understanding. In this context, a requirement can be defined as a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (PowerTest2010). According to D2-5 the following aspects are defined:
• Functional requirements identify what is required from different user perspectives. They are related to the use of the REACTION platform in the clinical settings and to the user expectations.
• Non-functional requirements are the properties that the platform must have such as performance, usability, security, legal, ethical, business and they are as important as the functional requirements.
• Technical requirements documents technical aspects that a system has to fulfil. This can performance related issues, reliability or availability. Often the term quality of service (QoS) requirements is used for these kinds of requirements. Many technical requirements can be thought of as quality attributes or constraints.
• Constraints are restrictions imposed to the platform due to the budget, the time or the way the platform is designed or will work or interact with third-party components.
4.1.2 Use cases
A use case diagram provides a visualization of user requirements. Instead of simply asking the users what the system should do, use cases help to examine what users need to accomplish. Use-cases therefore describe the main tasks users should be able to perform. (Wiegers2003) As use cases are a common practice for capturing functional requirements they have been used in D4-3 for the requirement elicitation process of the REACTION prototype applications.
The term Business Use Case1, defines the interaction of stakeholders with the business that achieves a
business goal. Regarding REACTION a stakeholder is for example a physician. The business goal can be, for example, finding the right dose of insulin for the diabetic patient. In order to achieve this goal the business would in this case be an electronic decision support system. Thus, a use case diagram comprises the following elements, see Figure 1 (Podeswa2010):
• Business actor: Roles played by organizations, people, or external systems to the business (e.g. physician, nurse, diabetic patient, Hospital Information System)
• Business use case: Services and functions requested by the business (e.g. exchange clinical documents, measure blood glucose, electronic decision support)
• Association: An association between a business use case and an actor indicates that the actor interacts with the business over the course of the business use case (e.g. a physician uses the electronic decision support system for insulin dosing for his or her patients in the ward)
1 In order to align with D2-1, instead of the term “Business Use Case”, which is a widely used notation in the technical domain, the
term “workflow” analogically can be used for the healthcare domain.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 12 of 85 DATE 2010-08-31
Figure 1: Use Case Diagram
D4-3 provides the starting point for the use-cases of the prototype inpatient and primary care applications and bridges the gap between initial user requirements and technical functional requirements for a REACTION data management model.
4.2 Bridging the Gap between User and Technical Requirements
Starting from the clinical partners, who desired a close alignment of the REACTION platform functionalities with prevailing clinical practice and medical reality, short-term needs were identified in two workshops which generated present clinical workflows in both in-hospital and primary care settings.
Additionally, a future scenario brainstorming session was carried out, which generated long-term requirements relating to key technological, security, socio-economic and business drivers for future end-user requirements. The results of the workflows analysing process and future scenarios were documented in D2-1.
As a next step, initial user requirements were derived from these workflows and scenarios. Each WP partner was responsible for extracting the detailed technical requirements and evaluating their architectural influence. Finally, conflicting, overlapping, obsolete or erroneous requirements were modified. D2-5 summarized the results of the initial user requirements phase.
All the steps have been carried out using a user-centred design approach according to ISO 9241-210 standards. In accordance with this evolutionary requirements engineering approach, D2-5 proposed the following iterative template:
• User requirements engineering and refinement
• Architecture design specification and refinement
• Clinical protocol and medical context planning
• Technologies research and development to implement architecture
• Integration and prototype development and field trial preparation
• Field trials in clinical domains
• Conformance testing, usability evaluation and user acceptance testing
• Lessons Learned and change analysis
D4-3 is an important initial working point for WP4. The objectives of WP4 are to research, develop and implement the complex Data Management structure of the REACTION platform. Therefore, the work package will design and implement a semantic data management server that will provide the necessary information management and service orchestration functionality to support the REACTION requirements.
The main objectives of WP4 can be summarized as follows:
• Analyse and define the overall architecture of the Data Management structure
• Define data structures, taxonomies and ontologies for the service components
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 13 of 85 DATE 2010-08-31
• Research and develop a Data Management structure that provides a model-driven architecture for application development and deployment
• Research and develop a service oriented architecture with service ontology with high level concepts to be used in both development and run-time processes.
• Design and implement a context management framework and a context awareness mechanism capable of managing patient and user data across different contexts and situations in the REACTION architecture.
• Research and develop a rule-based service orchestration engine that allows for the static or dynamic assembly of services and their execution on the REACTION platform. This would be a basis for application-oriented workflows, including event handling and crisis management.
• Develop a resilient and intelligent event handling mechanism that can support crisis management and provide an interface to established emergency centres.
In the light of the enumeration mentioned above, D4-3 covers the initial task of analysing the technical requirements for a specific medical data management model for the REACTION platform. Based on the elicited requirements, a suitable architecture for the data fusion/diffusion model in a device and network oriented environment and the technology to implement it in the REACTION platform will be specified.
In preparation for the requirement elicitation phase, the draft version of a technological platform for REACTION, which was identified in the initial requirement phase of D2-5, was subdivided into the following six categories:
• Mobile Devices (PAN/BAN)
• Middleware, Internal communication
• Core server infrastructure
• External communication
• Security
• Overall platform
“Overall platform” contains technical requirements which are relevant to all categories. Each category was assigned to one or two partners in order to perform the requirement elicitation. The partners gathered technical requirements for the REACTION data model in JIRA. Furthermore, typical use-cases were identified and requirements regarding the data model for the two pilot applications - (1) inpatient glucose control and (2) Primary care diabetes management were gathered.
The following steps have been defined and carried out in D4-3:
Step 1:
In order to obtain a shared notion of what REACTION, from a technical point of view, will be, typical use-cases for inpatient insulin dosing and primary care disease management as well as a draft architecture for the REACTION were generated.
Step 2:
Based on the use-cases and on the draft architecture, an intensive discussion among involved partners was initiated. Suggestions for improvements arising from this discussion were incorporated and the draft architecture and use-cases were distributed to involved partners (see Appendix I)
Step 3:
Questions concerning system components, which may be interesting in eliciting technical requirements for the REACTION data management model, have been formulated and distributed to involved partners (see Appendix I).
Step 4:
In order to define a data management model we need to specify and define the following aspects:
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 14 of 85 DATE 2010-08-31
1. Data Interface, including both internal interfaces between components and interfaces to external system.
2. Data Source, which are the sources of the data that need to processed and managed by the REACTION platform, ranging from measured raw sensor values to medical knowledge structures. Particular emphasis will be placed on PAN and BAN.
3. Data Storage, i.e., what are the needs for persistent as well as temporary storage of data.
4. Data Structure, which are the basic data structures we need to define.
5. Data Semantics, what are the requirements on the interpretation and understanding of the clinical data generated and maintained within the REACTION platform.
6. Data Security, i.e., issues including protection, privacy and informed consent.
Step 5:
JIRA has been set up for the elicitation of technical requirements (see Section 4.3.1). In the first iteration, each identified system component was assigned to one or two involved partners. The partners were responsible for eliciting technical requirements concerning the influence of the assigned component on the data management model. Each partner entered the identified technical requirements into JIRA. In the second iteration each partner went through all identified requirements and resolved conflicting, overlapping, obsolete, or erroneous requirements. The re-engineered list of requirements is documented in Appendix II: Complete set of Technical Requirements for a Medical Data Management Model.
In the next step improvements in the already derived business use-case models were incorporated into the inpatient and primary care prototypes from the initial requirements report. The use-cases will support the implementation of system use-cases in a subsequent step of the development phase (see chapter 6).
Step 6:
Finally the requirements were stratified by data management model aspects which are described in Step 4. For each aspect (corresponding to requirements subtype), the outcome of the requirement elicitation phase was summarized and related to the needs of a REACTION data model as well as of the entire architecture, taking into account that the REACTION pilot applications need further steps of analysis.
The early stage of the project combined with the ambitious overall aim of the REACTION project that covers wide areas of the treatment of diabetic patients, mean that current elicited requirements are not as technical as expected. Nevertheless, D4-3 enables partners to gain a clear understanding of the main use-cases of the prototypes and to consider how technical solutions can help to implement a data management model that provides a sufficient technical basis for fulfilling the requirements of use-cases.
4.3 Tools for Supporting the Requirement Management
4.3.1 JIRA Issue Tracker as RM tool and Structure of Requirements
Building on previous positive experiences with the JIRA Issue Tracker as a requirement management tool in D2-5, we decided to use the tool for requirement elicitation of D4-3. We added a new project named REACTION data management model requirements (RDMM). According to D2-5 a new issue type based on the Volere requirement template (Robertson2006) was created. The main reasons for the usage of the Volere template are: (a) the Volere Scheme is the atomic structure of the REACTION requirements; (b) there was a need to simplify the user interface and limit the possibility of errors from a generic user; (c) the Volere template has proven good usability and covers the main fields needed for the technical requirement elicitation.
In addition, we customized the existing Volere configuration for D2-5 in order to fit it to the special needs of D4-3. The following fields summarized in Fields marked * are compulsory.
Table 1 have been defined for the partners of T4-3 to enter their requirements into JIRA:
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 15 of 85 DATE 2010-08-31
Field Name Description Type Value/Values
Requirement # A 3-digit number that is created by
the system when a new issue is added
Auto incremented key
RDMM-XXX
*Requirement Type
Type of requirement or
constraint
Cascading Select (Consists
of two Select Lists, where the values shown in
the second depend on the value that has
been selected in the first)
� Functional
• Inpatient pilot application
• Outpatient pilot application
• REACTION platform � Non-functional
• Look and feel
• Usability
• Performance
• Operational
• Maintainability and portability
• Security
• Cultural and political
• Legal
• Ethical
• Economical and business � Constraint
• Solution
• Implementation Environment
• Collaborative Applications
• Off-the-Shelf Software
• Off-the-Shelf Sensors & Devices
• End-User Workplace Environment
• Schedule
• Budget
*Requirement subtype
Subtype of requirement or
constraint
Multi Select List � None � Data interface � Data security � Data source � Data storage � Data structure/data
representation � Other
*Component/s Component/s to which the
requirement is related
Multi Select List � Mobile Devices (PAN/BAN) � Middleware, Internal
communication (Hydra) � Core server infrastructure
(service, storage, N) � External communication � Security � Inpatient glucose control � Overall platform � Primary care diabetes
management � Other
*Workpackage Workpackage/s to which the
requirement is
Multi Select List � WP1 � WP2 � WP3
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 16 of 85 DATE 2010-08-31
related � WP4 � WP5 � WP6 � WP7 � WP8 � WP9 � WP10 � WP11 � WP12 � WP13
*Priority Importance of the requirement
Select List � Blocker � Critical � Major � Minor � Trivial
Asignee Person in charge of resolving the requirement
Select List Users Full Names that have access to the “REACTION Data Management Model Requirements” project
Reporter Person who specified the requirement
Text Field (< 255 characters)
* Summary A one sentence statement of the intention of the
requirement
Text Field (< 255 characters)
*Rationale A justification of the requirement
Free Text
*Source/Originator
The source where this requirement
was raised
Free Text
*Fit Criterion A measurement of the requirement
such that it is possible to test if
the solution matches the
original requirement
Free Text
* Customer Satisfaction
Measures the desire to have the
requirement implemented
Select List � Uninterested � Interested � Pleased � Very Pleased � Extremely Pleased
*Customer Dissatisfaction
Unhappiness if it is not implemented
Select List � Very Low Unhappiness � Low Unhappiness � Neutral Unhappiness � High Unhappiness � Extreme Unhappiness
Conflicts Other requirement that cannot be
implemented if this one is
Text Field (< 255 characters)
Dependencies Other requirements with a change
effect
Text Field (< 255 characters)
Fields marked * are compulsory.
Table 1: Definition of JIRA issue to map data management model requirement
The significant linking of issues was used for the phase of requirement consolidation in D4-3. The linking of issues within D4-3 was necessary, as was the linking of issues between packages. Many requirements
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 17 of 85 DATE 2010-08-31
of D4-3 are a specialization of already existing requirements of D2-5. Hence issue linking was very helpful to trace the path from initial user requirements to the detailed technical requirements and in turn to the final system specification. In addition the JIRA notification system was activated to improve communication and collaboration of project partners.
For the detailed user guide for JIRA issue tracking in REACTION we refer do chapter 5 of D2-5.
4.3.2 MagicDraw UML Design Tool
We designed use cases for the application prototypes using MagicDraw V16.82. MagicDraw is a business
process, architecture, software and system modelling tool with teamwork support and improved support code engineering mechanism for a wide range of programming languages. MagicDraw supports UML metamodel and notation, class diagrams, use-case diagram, sequence diagram and many more sophisticated IT-modeling modules.
For D4-3 we used the use-case functionality of MagicDraw. The main reason for using MagicDraw was its wide range of visualization and functional possibilities and its availability at MSG.
4.4 Towards a REACTION Data Model
D4-3 is one building block for the design of a REACTION data model. It delivers fundamental requirements concerning user and technician expectations of REACTION data management. Figure 2 shows a first draft of the data management part of the initial REACTION architecture. The focus in Figure 2 is on the data management to highlight the context of the requirements and not to the complete architecture. It is a first conceptual sketch. The following three parts correspond to the blocks in the figure (left to right).
• Patient vital signs captured with sensors
• Data management on the hosting client for individual patient measurements and observations
• Data management on the hosting server for individual patients treatment
• Data mining and analysis of historical data across patient populations
Another important component for the REACTION data model will be provided by D4-2 data structures, taxonomies and ontologies which manage contextualisation of data, based on semantic modelling and a knowledge representation framework. Communications standards within BAN and PAN prepared in D5-1 and finally the first internal version of D4-1 State of the Art – Concepts and technologies for a unified data fusion architecture will provide further input for T4-3 Data management.
2 http://www.magicdraw.com/
Fig
ure
2: D
ata
Man
agem
en
t vie
w o
f th
e R
EA
CT
ION
arc
hitectu
re
5. REACTION Platform: Technical Requirements for a Data
Management Model
When designing a healthcare data architecture that fits a particular need, there are many factors – some more important than others – that determine the optimal architecture.
At this initial stage, the REACTION project faced the well-known gap between clinical user partners’ expectations and technological possibilities. The two initial workshops held in London and Graz aimed at bridging this gap helped in the specification of the clinical workflows in outpatient and inpatient settings. The two days workshop also provided information about clinical needs and enabled a common understanding between technical and medical points of view to be reached. In order to provide a semantic integration of a multitude of heterogeneous medical devices and media, information sources, services and communication, the Data Management requirements elicitation has been quite strict.
With the requirements phase, we have defined the restrictions and user needs (from a technological point of view) in order to define future steps for components of the REACTION architecture. The final goal is to decide upon (a) the interfaces and communications channels between the different parts of the system, (b) the information to be exchanged (clinical, daily life, demographic, etc), (c) the structures which we need in order to store data in a sufficient and efficient way, (d) the ensurance that the processed data will be presented in a satisfactory manner, and (e) the security mechanism to protect the data privacy.
Taking into account all of these issues, the REACTION system will improve the continuous glucose monitoring (CGM) and insulin therapy by means of contextualized glycaemic control based on patient activity, nutrition, interfering drugs, stress level, etc. for the proper evaluation and adjustments of basal and bolus doses.
Therefore, this chapter presents the technical requirements stratified by their main requirement subtypes. Considering that a single requirement can have more than a single sub-type, each requirement has been listed in this deliverable in the sub-type with most significant impact. Whilst the elicitation was conducted with a view to the main layered components of the REACTION platform, we choose a more abstract stratification by subtypes with focus on data management for the report. Following subtypes
3 have been
defined for the REACTION data management requirements:
• Data Interface
• Data Source (with focus on PAN/BAN)
• Data Storage
• Data Structure
• Data Semantics (including data (re)presentation)
• Data Security
The sections that follow provide a short introduction to describe the main aim of the subtype related to the data management model. In addition the sections enumerate the gathered technical requirements ordered by requirement identifier. Finally the conclusion section examines the expected impact of the requirements on the further design process of the data model and architecture.
5.1 Data Interface
The REACTION platform will provide communication interfaces with numerous users, external systems, and internal components. This section describes what main interfaces are required.
5.1.1 Introduction
In order to yield the maximum value from current and future technological research, it is necessary to understand the importance of the Data Management architecture model. It is also necessary to ensure the robustness, accuracy, topicality (up-to-date-ness), and availability of clinical data assets as well as access to those assets. This section illustrates the communication requirements of the REACTION
3 Requirements assigned to the subtype „Other“ are not relevant for data management and therefore are not shown in section 5.
They are listed in Appendix II.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 20 of 85 DATE 2010-08-31
system- representing different access to the information- and their respective needs regarding availability and accuracy (or suitability for use) of this data.
This section provides background information on how we should proceed to support our communication interface work in the REACTION project in order to define the requirements needed to connect the different components which play a role in the ”long term management of diabetes through continuous glucose monitoring, monitoring of significant events, monitoring and predicting risks and/or related disease indicators, decision on therapy and treatments, education on life style factors such as obesity and exercise and, ultimately, automated closed-loop delivery of insulin”. The communication within the REACTION project is the corner stone in exchanging clinical and daily life information between the sensor devices, the REACTION Hosting Client, the Device Hosting Server, the patient and carer sphere and the third parties (Microsoft HealthVault and Google Health) using several standards (IEEE 11073, IHE-PCD01, HL7, etc).
We will document where the standardized interfaces (e.g. HL7) have to be used, e.g. to retrieve demographic information of the patient and to exchange clinical data with the LIS / HIS / EPR / third parties and the inpatient pilot. The specific subset of IEEE 11073 medical devices to be supported, the communication methods (two way communication) and the recovery mechanisms in case of failure will be taken into account. The availability of mechanisms to provide communication channels with authenticity, integrity, and confidentiality in order to minimize risks and preserve privacy will be studied in section 5.6 Data security.
5.1.2 List of Requirements
Key Summary Rationale Fit Criterion
RDMM-3 Interface to patient
demographic register
In order to import demographic data
from the patient demographic
register has to be imported from the
HIS. A standardized interface e.g. HL7
has to be used for data interchange.
Required data fields are.
- unique PID
- name
- age (data of birth)
- sex
- address
Standardized interface (HL7) to
patient demographic register is
available for the inpatient pilot
application
RDMM-26 Interface to Lab
Information System (LIS)
for glucose data import
In order to perform decision support
the blood glucose value has to be
imported from the Lab Information
System (LIS). A standardized interface
from inpatient pilot application to the
LIS has to be defined. HL7 would be a
suitable standard.
Standardized Interface (e.g.
based on HL7) to Lab
Information System (LIS) for
glucose data import.
RDMM-27 IEEE 11073 support The support for a specific subset of
IEEE 11073 medical devices has to be
provided.
Once specified which medical
devices have to be supported,
show that data can be collected
from at least two of them.
RDMM-28 Interface to Hospital
Information System for
clinical data
import/export
In order to exchange clinical data
between inpatient pilot application
and Hospital information System (HIS)
an interface based on HL7 has to be
provided.
Standardized Interface (HL7) to
HIS / EPR to exchange clinical
data.
RDMM-33 Data exchange with third
party systems
Ideally integrates information from
outside the REACTION platform (e.g.
Laboratory Information Systems in
hospital or primary care with blood
glucose and glycated haemoglobine).
Should be able to import and
export data in an interoperable
way (e.g. HL7) to third-party
systems.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 21 of 85 DATE 2010-08-31
RDMM-34 Interface for user inputs
from portable computer
in order to store data in
inpatient data storage.
For the inpatient prototype user input
should be possible. The user data
should be stored in the data storage.
User input can be stored in the
inpatient prototype storage for
further processing.
RDMM-35 (Web) Service to present
decision support for
glucose control to
clinicians
After processing of data by the
glucose prediction algorithm, the
results should be presented by the
system to the physician. The physician
can use the result for decision
support. The service uses data stored
in the data storage and user
additional user input as input for
processing.
A service will be available to
support physician with glucose
control of patients.
RDMM-36 Interface for transmission
of glucose values from
POCT system to inpatient
prototype
As decision support is a time critical
process data from the POCT device
should be transferred directly
(without detour to LIS) to the
inpatient prototype in order to speed
up the transmission process.
Therefore an interface has to be
provided.
Interface to POCT device is
available for the inpatient
prototype.
RDMM-52 Patient enrolment (or
recruitment)
When an interoperable HIS or EPR is
present in the managing organization,
then the patient data at the patient
enrolment should be obtained from
the HIS or EPR through interoperable
user interfaces.
When an interoperable HIS/EPR
is present a new diabetic patient
cannot be created in the
REACTION platform if not
present in the HIS/EPR. When a
diabetic patient is created his
data have to be taken from the
HIS/EPR.
RDMM-73 Data should be stored in
proper way in order to be
easily transmitted over
mobile networks in case
that broadband network
is not available.
In the event that the hosting client is
not connected through a broadband
connection the patient will be able to
upload data using GPRS / 3G data
networks. In this case we need to
examine possible limitations.
Functional test uploading data
over slow mobile networks.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 22 of 85 DATE 2010-08-31
RDMM-108 Two-way communication
between REACTION
server and client
There is a need for two-way
communication between server and
client e.g. for remote configuration of
the end-user application running in
the AHD. The data fusion engine also
needs to be configured based on
which values the clinician wants to
observe. There is also a need for 2-
way communication from the point of
view of error handling. If the observed
values suddenly appear out-of-range
it might be necessary to check with
the client if this is an error state.
Other devices/sensors, e.g. the
Continua-devices, might also require
different types of communication.
It might be necessary to reverse a
patient's consent that had to be given
'remotely', e.g. at the doctor's
surgery, because the hosting client at
the patient's home is simply a 'box'
with no display or input capabilities.
In this restricted 'boxed case', it
would be hard to change the patient's
privacy settings, once they are initially
configured, if we were unable to push
data back to the box.
Two way communications
between Client and Server will
be available for the REACTION
platform in order to perform:
e.g. data fusion configuration,
error-handling, data security
(consent management).
RDMM-109 Support of continua
compliant devices
REACTION platform should provide
Continua compliant devices.
The REACTION platform
supports Continua compliant
devices.
RDMM-113 Communication interface
between REACTION Client
and REACTION Server
A communication standard between
REACTION client and server should be
established (e.g. IHE-PCD01) in order
to transport data from client to server
side (and vice versa).
Communication interface
between REACTION Client and
REACTION Server will be
available.
RDMM-117 IEEE 11073-20601
compatibility of Solianis
device
Solianis would like to provide IEEE
11073-20601 compatibility (IEEE PHD
protocols) for their blood glucose
device.
REACTION middleware supports
support IEEE PHD protocols.
RDMM-121 Connection with external
services like MS
HealthVault and Google
Health
External interfaces to services of MS
HealthVault and Google Health should
be taken into account in the
REACTION platform.
Interfaces to MS HealthVault
and Google Health will be
available.
RDMM-122 Maximum delay to
transfer blood glucose
value from POCT to
inpatient prototype
Up-to-date Blood glucose values are
absolutely necessary for electronic
decision support. In order to improve
usability for physicians the transfer
delay from POCT device to inpatient
server application should be max. 3
seconds. Therefore the interface has
to be appropriate to fulfil this
constraint.
Delay of blood glucose transfer
is max. 3 seconds.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 23 of 85 DATE 2010-08-31
RDMM-123 Inpatient prototype
communication with
REACTION platform
The current design of the inpatient
prototype and the primary care
prototype does not consider the
communication between these two
prototypes (e.g. SoA). Thus, the data
model should consider how the
prototypes can be merged in future
within the REACTION platform. A
data/communication interface has to
be defined.
Communication and transfer of
data between inpatient and
outpatient prototypes are
possible.
RDMM-128 Connection with other
external services
External interfaces to services of MS
HealthVault and Google Health should
be taken into account in the
REACTION platform (RDMM 121).
Other external services should be
taken into account in the future.
Interfaces to other external
services could be available
(scalability).
5.1.3 Conclusion
The REACTION platform will implement a distributed system. This implies that the systems architecture will expose a number of different information exchange and data communications interfaces, internally as well as externally.
The requirements in this section address these interfaces with regards to their purposes and roles. We distinguish the following different types of data interfaces,
• External, i.e.,
o Interfaces to other health-care sub systems, including EPRs, demographic databases
o Interfaces to global services, like MS HealthVault and GoogleHealth
• Internal (inter component messaging and service invocation)
• Persistent storage media
• Medical devices
• Data entry/capture (for patients and carers)
Several of these interfaces will expose or be forced to comply with, various standards, primarily those intended for eHealth interoperability.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 24 of 85 DATE 2010-08-31
5.2 Data Source (with focus on PAN/BAN)
This section discusses data sources which are relevant for the REACTION platform. Particular emphasis is placed on BAN and PAN and data which are gathered by their devices.
5.2.1 Introduction
It is evident that the mobile devices and sensors comprise the forefront of the medical management model we design, whatever its architecture may be. The PAN sub-system is responsible for a series of operations and functionality, and must be able to ensure stability under all circumstances without compromising unquestionable requirements such as the safety of a patient or privacy and confidentiality of his medical data.
The BAN and PAN devices are responsible for collecting most of the medical measurements of a patient, along with any context information and environment factors which we want to gather and correlate, by using environment sensors or other ambient and background information. In addition, by using PAN devices we also collect medical data which is not collected automatically and have to be inserted manually or inferred by other pieces of information like external knowledge base systems, and questionnaires which complete our medical view of a patient or an episode. In addition to the data generated by PAN&BAN devices and sensors, other sources of data we need to process and managed through the REACTION platform, are EPRs, knowledge data bases, or historical data sets.
Apparently, the collected requirements are based on a first evaluation of the system architecture and as the project progresses, even more concerns and demands will arise from the end users, the technical restrictions or even from the overall system architecture. With an iterative and systematic approach we expect that gradually and progressively we will reach the convergence point between the limitations and the required functionality.
Based on these observations and facts, we collected the requirements which are summarized below. Due to the stratification of the requirements by data management related aspects not all requirements for PAN/BAN are summarized in this section. The complete set of PAN/BAN requirements for a REACTION data management model can be found in Appendix II: Complete set of Technical Requirements for a Medical Data Management Model.
5.2.2 List of Requirements
Key Summary Rationale Fit Criterion
RDMM-31 All data entered must be
checked for format,
consistency and validity
Unintended user actions should not
harm data integrity and the overall
functioning of the platform. In case of
doubt, the user must be warned and
asked how to proceed. The user must
be able to correct mistakes easily.
The functional test should
include specific tests in order to
verify such circumstances.
RDMM-80 Patient education Continuous education of the patient
adjusted to his/her needs.
Educational material is available.
RDMM-82 Manual data insertion In case of no connectivity with the
sensor or medical device or use of a
non-interoperable medical device, the
mobile device should offer the
possibility of manual insertion of
measurement data .
Check that measurements can
be inserted manually using the
mobile device.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 25 of 85 DATE 2010-08-31
RDMM-86 Device specialization Based on the necessary information
to be monitored from the patient, a
complete list of IEEE 11073 device
specialization has to be completed.
Measurements which cannot be
collected using IEEE 11073 device
specialization are also to be
mentioned in this list. The complexity
of the IEEE 20601 manager also
depends on the number of device
specializations to be managed.
For each device the supported
standard has to be specified (or
the company documentation).
RDMM-87 Continuous blood glucose
monitoring
Using the acquired values, the mobile
device must be able to analyze the
glycaemic variability and to generate
alarms or alerts (hypo or hyper),
based on configurable thresholds.
This functionality can be tested
using the device simulator and
simulated sequences of values-
RDMM-88 Patient questionnaires
(lifestyle, physio-
psychological condition,
medication compliance,
education, self
management)
Questionnaire for patients in order to
collect qualitative (or quantitative but
not directly measurable) information
related to the parameters to be
monitored has to be available. They
are part of the monitoring (using a
frequency set) administered by the
responsible clinician.
The mobile device shall have
user interfaces allowing
completion of these
questionnaires.
RDMM-89 Collecting measured data
("many to one" traffic
pattern)
Different sensors can have different
acquisition rates and relay data at
different frequencies. Specific policy
for data aggregation/fusion has to be
defined.
Check the measurements
collected by different sensors
(times & values) and evaluate if
there are critical delays.
RDMM-90 Use of activity patterns
for context annotations
Context has to be expressed
synthetically in some way. A possible
and common option is through
activity patterns (to be specified for
the two environments).
Collect measurements about
physical activity, environmental
data, additional information, and
evaluate the activity patterns
verifying their correctness.
RDMM-92 Insertion of baseline
physiological
measurements at the first
visit
At the first visit baseline physiological
measurements (the exact set has to
be clearly defined) have to be
inserted in the platform.
The data management shall
foresee the possibility of
introducing the baseline
physiological measurements at
the first visit (just after the
patient enrolment).
RDMM-94 Measurements of blood
glucose and insulin
injections in Inpatient
environment
In inpatient environment, the blood
glucose level measurements are, in
most cases, performed by nurses with
treatment performed by clinicians
and/or nurses
Measurements of blood glucose
and insulin injections are tasks
performed by clinicians and/or
nurses. They have to store the
relevant data in the system or to
start the procedure for the
storage of the relevant data in
the system.
RDMM-95 Basic workflow in
Inpatient environment
The basic workflow is based on
measurement of blood glucose and
evaluation of the necessary insulin
(bolus or basal), based also on
additional parameters and insulin
administration.
There should be the possibility
of acquiring, storing and
retrieving all the information
generated during any basic
workflow performed during any
time of the day/night.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 26 of 85 DATE 2010-08-31
RDMM-101 Drug administration data
(OAD and/or insulin)
Drug administration (time, insulin
type, administration type -IV or SC-,
dosage and other relevant
information) has to be immediately
registered in the data management by
the administering nurse.
Data on drugs administered have
to be stored in the data
management where they can be
also retrieved as part of the
fever/sugar chart.
RDMM-102 Special
examinations/treatments
to be registered in fever
chart
For some examinations/treatments in
the hospital the patients have to be in
a fasting and/or glycaemic condition.
In such cases treatment must
therefore be adjusted to the
particular needs (e.g. during fasting
conditions the insulin dose is
decreased). However a problem may
arise if the patient has to wait longer
than expected due to unforeseen
delays. This may result in glycaemic
excursions (hyper- or hypoglycaemia).
The dose of insulin and/or OADs will
therefore need to be adapted, the
patient receives some food in the
event of hypoglycaemia and receives
insulin by injection in the event of
hyperglycaemia.
These events (special
examination/treatments) have
to be registered in the data
management where they can be
retrieved for the composition of
the fever/sugar chart.
5.2.3 Conclusion
A list of requirements is provided for the Data Management, based on the restrictions and facts imposed by the BAN and PAN components of the REACTION architecture. These requirements are drawn from the preliminary REACTION architecture (see section 10.1), in conjunction with the collected set of requirements for the overall REACTION project (see “D2-5 - Initial Requirements Report”) and the state of the art analysis regarding the BAN and PAN network structure and communication standards (see “D5-1 – Communication standards within BAN and PAN”). This list of requirements is expected to evolve together with the project architecture and will be refined as more input is collected both from the medical and the technical experts.
As we outlined above, the PAN and BAN devices comprise the fore interfacing sub-system of REACTION with the patient and his environment, thus must conform and take into account a number of factors, and harmonize or even trade-off between many legal requirements, technical restrictions, and functionality goals. The REACTION system has been foreseen to be used at different kinds of installations, both for remote monitoring of patients at home, or monitoring and applying the close-loop system on real patients in controlled environment.
The challenge in the PAN and BAN networks is to ensure interoperability, data consistency, privacy, low complexity, especially in the BAN network, and to decrease power consumed by the sensors. Moreover the data transmission from the devices and sensors must be secure and accurate. Faultless data transfer across the standards such as ZigBee, Bluetooth etc. must be retained. In addition to that plug and play device interaction must be endorsed and the systems must be scalable for further changes to facilitate well functioning.
The contextualization of measured values, such as blood glucose values, is an important factor to facilitate support for the REACTION applications, like decision support. The data management model has to provide context management due to different glucose levels that have different meanings for treatment which is essential.
Based on the above facts and observations, the system must be able to ensure smooth operation. In order to achieve this, the system’s fault tolerance, the operation under restricted power consumption, possible problems in communication, logging and caching of data acquisition must be taken into account.
Furthermore, in order to follow for example the Continua guidelines, the devices must conform to some specific standards and/or the middleware must be designed and implemented in a way to ensure this seamless integration. Requirements like the ability of the system to collect also manual measurements,
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 27 of 85 DATE 2010-08-31
context information and environmental data are inevitable. Besides the automatic fetching of measurements, the system must support manual data insertion, for functional and technical reasons. All the data entered must be checked for format, consistency and validity in order to avoid unintended user actions that might harm data integrity and furthermore the overall functioning of the system itself.
Having mentioned all the above, the BAN and PAN devices are the first step on a series of actions which will ensure an open and flexible architecture. In order to satisfy the requirements for interoperable data formats and models, the devices and the middleware, should comply with the relevant standards, e.g., the IEEE 11073 set of medical device standards.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 28 of 85 DATE 2010-08-31
5.3 Data Storage
This section deals with requirements on the data content to be maintained within the REACTION platform.
5.3.1 Introduction
In all three parts of the REACTION platform (see Figure 2) there are needs to store data both temporarily and persistently. On the patient (client) side the measured values might not be possible to transfer to the hospital (server) side due to lack of connectivity and therefore data needs to be temporarily cached. The server side needs to manage a variety of information objects and data types, ranging from individual patient observations and treatment plans to aggregated population data. Thus, we need to store patient measurements and related context data, and in order to perform analysis and generate new knowledge related to diabetes treatments we also need to store large sets of historical and statistical data for current and historical patient populations. The following requirements have been elicited so far.
5.3.2 List of Requirements
Key Summary Rationale Fit Criterion
RDMM-30 Integrity check for the
stored data
To guarantee the integrity of the
stored data in the case of an
unwanted happening.
Use of adequate methods like e.g.
Hash keys or redundancy codes
for the data stored.
RDMM-32 Dynamic data structure
for inpatient data
storage
For the impatient pilot application
(eDSS) a dynamic data structure for
data storage has to be implemented.
Data fields should be flexibly defined.
A suitable model can be the Entity-
attribute-value (EAV) model.
Dynamic data structure for data
storage will be available for
inpatient pilot application.
RDMM-42 Set of alerts and
reminders
A set of possible alerts and reminders.
These can be thought as
“prototypes”. Action rules can define
when and how they must be sent with
which parameters.
Alerts and reminders can be
defined and stored.
RDMM-53 Provide regular update
of data model for Health
Care profile
Most application depends on current
clinical data (e.g. blood glucose). A
mechanism for regular data updates
should be provided.
The Data Model for REACTION
should provide a regular update
mechanism for personal health
care profiles.
RDMM-54 Results of screening,
symptoms and types of
diabetes or
hyperglycaemia
At the diabetic patient enrolment
his/her symptoms or results of
screening confirming presence of
diabetes should be registered.
Symptoms can be: polydipsia,
polyuria, blurred vision, weight loss,
tiredness, and recurrent skin
infections. Results of screening can
be: glucosuria or elevated BMs (both
have to be confirmed with a
diagnostic blood glucose
measurement). Type of diabetes
should be registered (if available data
can be taken from the HIS/EPR).
Possible classifications should be
present in the knowledge base &
ontology and in the database
fields for multiple selections from
the classifications. Does the data
need to be stored at each
subsequent visit or evaluation?
RDMM-58 Different stages of
patient management in
outpatient environment
Different actions have to be
performed at different stages (newly
diagnosed / medication titration /
investigative stage, ongoing
management) of patient management
in outpatient environment.
The data management has to
allow the storage of the stage of
management for each patient.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 29 of 85 DATE 2010-08-31
RDMM-60 Investigative stage An investigative stage is required for
all newly diagnosed diabetic patients.
This stage (the duration of which is
determined by clinicians) is used to:
confirm diagnosis, check effectiveness
of lifestyle and medications, evaluate
the optimal dosage of medications,
carry out patient education , and
reassure patients concerned about
their blood sugar levels.
Specific fields have to be present
in ontologies and data
management.
RDMM-61 Ongoing management Ongoing management follows
investigative stage. This stage is used
to: support patients with difficulties in
managing their diabetes, check
effectiveness of lifestyle and
medications, evaluate the optimal
dosage of medications, perform
patient education on diabetes,
support changes in patient lifestyle,
identify better diabetes
Specific fields have to be present
in ontologies and data
management
RDMM-63 Measurements of
HbA1c
The risk of developing diabetic
complications is strongly affected by
HbA1c. This parameter has to be
measured every 2-6 months until the
blood glucose level is stable on
unchanging therapy in outpatient
environment and at the patient
enrolment in the inpatient
environment (updates are decided
buy clinicians).
Specific fields have to be foreseen
in data management.
RDMM-65 Storage of insulin
administration
Insulin administrated to patient has to
be stored with time, dosage (units),
type of insulin and modality of
administration (always subcutaneous
for outpatient environment).
Specific fields have to be foreseen
in ontologies and data
management.
RDMM-66 Storage of events for
context of
measurements
Significant events (e.g. nutrition, drug
administrations, and adverse events
like hypoglycaemia or
hyperglycaemia) have to be stored in
order to provide a context (together
with environmental measurements
and physical activity) for the acquired
measurements.
The data management should
allow the storage of all events
with impact on context.
RDMM-69 Reasons for end of
process in primary care
environment
There is no end of process in primary
care; the patient will only leave
primary care if he dies or leaves the
practice due to moving away from the
practice catchment area or voluntarily
stops to be monitored by the
REACTION platform.
Patient discharge from the
outpatient environment shall have
the following options: a) death; b)
patient removal outside from the
practice catchment area; c)
patient voluntarily stops to be
monitored by the REACTION
platform.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 30 of 85 DATE 2010-08-31
RDMM-71 Care space in primary
care environment
The primary care processes only end
in the event that the patient leaves
the practice catchment area;
voluntary withdraws from the
REACTION monitoring system or dies.
Patient discharge from the
outpatient environment shall have
the following options: a) death; b)
patient leaves the practice
catchment area; c) patient
voluntarily stops being monitored
by the REACTION platform.
RDMM-72 Information related to
informed consent stored
in the platform
An ethical approved declaration of
informed consent has to be signed
(either digitally or in paper form) by
patients before they can be enrolled
in the REACTION platform.
The enrolment procedure shall
allow the storage of the digitally
signed informed consent or of a
scanned copy of the signed paper
This procedure shall be completed
before any other operation can be
performed.4
RDMM-74 Baseline and clinical
history handled in the
data management
Immediately after patient
recruitment, his/her baseline and
clinical history has to be entered in
the platform. This can be done by
extracting this information from the
HIS/EPR (if available and
interoperable) and completing the
missing information.
The data management should
allow the storage of baseline and
clinical history and these data can
be extracted from the HIS/EPR (if
available and interoperable).
RDMM-75 Data should be
automatically saved in
temporary file when
PDA’s battery is running
out.
In case of low battery the client
application should be able to store
temporary data. This will a) allow user
to continue the process later and b)
prevent corrupted / incomplete data
to be uploaded to the main server.
The functional test should include
specific tests in order to ensure
that data are always stored
correctly in case of a battery-
forced shut down.
RDMM-76 Information should be
cashed in local storage
to prevent loss in case
of a node or
communication failure.
In case of network error the client
application should be able to store
temporary data. This will a) allow user
to continue the process later and b)
prevent corrupted / incomplete data
to be uploaded to the main server.
The functional test should include
specific tests in order to ensure
that there is no data loss in case of
network failure.
RDMM-77 Energy friendly data
aggregation for mobile
devices
Aggregation techniques should be
used for reducing the overall data
traffic to save energy. Depending on
the need for a real-time response, the
redundancy of the data, etc., specific
data-propagation strategies should be
defined.
The functional test should include
specific tests on battery
consumption using different
communication methods with the
sensors.
4 Requirements concerning data security and data privacy can be found in section 5.6.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 31 of 85 DATE 2010-08-31
RDMM-78 Clinical data to be
stored in the Inpatient
environment
The data management shall be
designed in order to allow the storage
of the clinical data to be registered at
the patient enrolment as well as other
clinical parameters which have to be
acquired more frequently.
The data to be registered at the
patient enrolment are: type of
diabetes (insulin requirement), newly
diagnosed diabetes,
weight/BMI/waist to hip ratio, HbA1c
(updated), fever, infection, diarrhoea,
vomiting, hypoglycaemia (last 3 days)
and hyperglycaemia, limited
renal/hepatic function, pancreas
operation, co-morbidities, therapy
scheme.
Other parameters have to be
measured more frequently: glucose
level, injected insulin, food
intake/nutrition, estimation of insulin
sensitivity and resistance.
The data management shall allow
the insertion and the update of all
the listed clinical parameters.
RDMM-93 Clinical case conference Any possible critical situation has to
be accurately verified by the clinical
care team with the support of virtual
visits through e.g. the use of video-
conference. The completion of the
accurate check shall be accompanied
by changes in the patient treatment
(if necessary) and also changes in the
RPM schema have to be allowed for.
A clinical case conference report has
to be stored.
Storage and retrieval of clinical
case conference reports has to be
possible.
RDMM-98 Clinical evaluation
report
Supervision of glycaemia and
associated treatment is performed
once a day. The clinical evaluation
report has to be produced daily.
Adaptation of therapy or changes of
medications has to be evaluated
including by consultation with the
duty-physician.
A daily clinical evaluation report
has to be stored and available in
the Inpatient application.
RDMM-99 Therapy scheme in
Inpatient environment
Decision on therapy has to be
performed immediately after
performing any measurements based
also on patient history and associated
parameters. It might imply changes in
the therapy scheme.
The pharmaceutical and non-
pharmaceutical treatment (or
therapy scheme) has to be stored
in the data management and can
be modified during any clinical
evaluation of the patient. It has to
be initialized immediately after
the patient enrolment.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 32 of 85 DATE 2010-08-31
RDMM-100 Insulin sensitivity and
insulin resistance
Insulin sensitivity and insulin
resistance have to be used in the
evaluation of the insulin dosage.
However, these two parameters
cannot be directly measured and have
to be estimated by the clinicians.
Their value can vary depending on the
context (physio-psychological status
of the patient, usage of specific drugs,
etc.).
The data management has to
allow for the insertion and
subsequent modifications of these
values by clinicians.
RDMM-103 Storage of
hyperglycaemic or
hypoglycaemic episodes
Reasons for any cases of
hypoglycaemia have to be registered
(overdosing of insulin, change in
nutrition, vomiting, changes in insulin
sensitivity and/or resistance, etc.) and
adequate treatment has to be
provided and registered. Should the
blood glucose level rise above a
certain threshold, a hyperglycaemic
episode has occurred. The reasons for
such an episode have to be registered
along with ensuing changes in
treatment..
Specific procedures have to be
present for the management of
hyperglycaemic or hypoglycaemic
episodes. These procedures shall
also allow for the recording of the
significant parameters and
actions.
RDMM-104 Nutrition information
has to be stored in the
data management
Composition (proteins, fat and
carbohydrates) of the meal has to be
recorded and used for the insulin
evaluation (the use of glycaemic index
and load tables for various types of
food might be taken into account).
Also other parameters have to be
taken into account (snacks in
between, fasting, special diet,
diarrhoea, vomiting,
diminished/absence of appetite). Also
special conditions related to nutrition
have to be considered (PEG tube /
parenteral feeding, fast adsorption of
IV administered fluids).
The data management shall allow
the insertion of time and
composition of nutrition
accompanied also by additional
(context) parameters. The dosage
of insulin shall vary with the
variation of the nutrition.
RDMM-105 Registration of specific
interfering drugs
(including their dosage)
Some drugs interfere with glycaemia
management: systemic interference
(e.g. cortisone by increasing blood
glucose), analytical interference with
glucose monitoring devices (e.g.
fructose, maltose- interference). Their
administration should be registered.
The data management shall allow
for the insertion of specific
interfering drugs (including their
dosage).
RDMM-106 Fever and infections
shall be registered
Fever is very often associated with
insulin resistance which means that
the patient needs more insulin.
Fever and infections shall be
registered in the data
management where they can be
retrieved for composing the
fever/sugar chart. When
estimating the insulin resistance,
clinicians shall have access to this
information.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 33 of 85 DATE 2010-08-31
RDMM-107 Ontologies and data
management designed
for the storage and
multi-user availability of
all relevant information,
actions, treatments,
events
Centrally managed data repositories
shall be designed and implemented
able to store and display (multi-user)
all the relevant information for the
diabetic patient management in the
Inpatient environment.
Data insertion and/or update and
data retrieval for patients shall be
possible in multi-user way.
RDMM-119 REACTION data storage The REACTION platform should
provide a storage module (database).
Data gathered within REACTION
should be stored here, as well as
relevant data from external sources.
The REACTION data storage should
also use security mechanisms to
include/exclude patient data access.
The REACTION platform provides a
persistence layer for data storage
with emphasis on data security
and data access.
RDMM-126 Communication failure
recovery
In case of communication failure, the
connection has to be restored as soon
as possible and the information
should not be duplicated or
corrupted.
Ensure that there is no data loss in
the event of communication
failure.
RDMM-127 User transparency in
case of communication
failure
In case of network error the client
application should be able to store
temporary data (RDMM 76). The
system should detect problems on the
network and start the local storage.
From the client’s viewpoint, failures
should be perfectly masked, and
service should be completely fault-
tolerant.
User transparency refers to a
combination of user friendliness’
and ‘high efficiency’.
RDMM-134 Sensor quality
parameters
The REACTION data management
model should consider data storage
for sensor quality parameters from
devices reports like for example mis-
calibration, or low battery. The
parameters should be used for QoS.
Data fields for sensor quality
parameters are available in the
data management model.
5.3.3 Conclusion
Storage requirements pertain to both the client (patient) side and to the server side (carers sphere). We need to provide for caching of data on the patient device, primarily in order to ensure reliable data transfers and to handle intermittently connected devices
Measurements obtained from the patient devices connected to the REACTION platform, should be maintained in a separate REACTION observations database. The measurements can be stored as a series of observations, each aggregating a measured value with its possible context data. A plausible standard representation for such an observations data model should be researched. The observations database should be provided as part of the platform back-end/server side. Data from EPRs and other sources which are needed for the data mining process needs to be extracted, aggregated and stored in a separate analysis database.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 34 of 85 DATE 2010-08-31
5.4 Data Structure
This section figures out what data structures have to be provided to store, process and interchange data in the most satisfactory way.
5.4.1 Introduction
Since we envision REACTION platform to be very flexible and able to support many types of disease management applications, we will need to support a model driven architecture, meaning that the execution of many functions are based on formal models and rules and that REACTION applications to a large extent are generated from models. Consequently, we need to understand and define which the fundamental data structures we need in REACTION are. The following requirements have been elicited so far.
5.4.2 List of Requirements
Key Summary Rationale Fit Criterion
RDMM-39 Data fields for the
inpatient glucose
control prototype
(eDSS).
Following data fields should be
provided:
- administrative data (patient name,
address, PID, ward, hospital bed,
physician(s) in charge, nurse(s) in
charge)
- demographic data
(age, sex, date of birth)
- medical history
(type of diabetes, medication, co-
morbidities, former complications,
pre-existing conditions)
- anamnesis data
(fever, infections, diarrhea, vomiting,
hypo- hyperglycemia)
- lab data
(glucose level, HBA1c, ...)
- external input
(food intake, insulin sensitivity, ...)
- context data
(time of glucose measurement, what
device, ...)
Required data fields will be
provided by data structure.
RDMM-45 Personal Health Status
Profiles
Personal Health Status Profile for
each patient must be generated,
stored and regularly updated. It
serves as an input for risk assessment
and disease management.
Personal Health Status Profiles can
be generated.
RDMM-48 Case base The case base contains a set of cases
generated in the platform and/or
imported from existing case bases. It
can be used together with other
knowledge elements (e.g. evidences)
to discover new knowledge.
A case base is present.
RDMM-51 Mechanistic model and
rules for insulin dose
prediction (primary
care)
A physiologic model and calculation
rules/algorithm must be stored for
insulin dosing support.
Necessary models and rules are
defined and stored.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 35 of 85 DATE 2010-08-31
RDMM-55 Co-morbidities have to
be registered
Co-morbidities are almost always
present in diabetic patient and their
presence can affect the overall
management of the diabetic patient.
In the design of data management
and ontologies the possibility of
registering the co-morbidities with
a basic set of attributes has to be
guaranteed. Co-morbidities with
their attributes have to be
registered at the patient
enrolment and at each
subsequent visit or evaluation
when new co-morbidities take
place.
RDMM-56 Annual clinical checks The annual clinical checks for the
outpatient environment includes
(with the necessary attributes): foot
check, retinal screening (photograph
of patient’s retinae), test for protein,
height and weight, BMI, blood
pressure measurement, check
smoking status, blood test (glucose
level, HbA1c, etc.), check/administer
flu injections, depression screening,
review of medication (including diet
and lifestyle measures).
Specific fields have to be present
in ontologies and data
management.
RDMM-57 6-month clinical checks Every 6 months the following tests
have to be performed: blood tests as
in the annual clinical checks (except
for the thyroid function tests), BMI,
blood pressure measurements, check
smoking status, review of medications
(including diet and lifestyle
measures).
Specific fields (entries) have to be
foreseen in ontologies and data
management.
RDMM-62 Non-pharmacological
and/or pharmacological
treatment
Non-pharmacological (diet, lifestyle,
education) and pharmacological
(OAD, insulin and interfering drugs)
treatments have to be assigned to
each patient and can be modified at
each check.
In the ontologies and data
management there should be the
possibility of registering the
different types of treatment for
each patient and of modifying
them at each check.
RDMM-67 Management of
complications
Apart from the diabetic management,
the other managements for diabetic
patients will be around the
complications (cardiovascular, renal,
ophthalmology, management of foot
and neuropathy problems).
Data management should include
the necessary structures for
assuring the storage of all
necessary information for the
management of complications.
RDMM-68 Outcomes of regular
visits at primary health
care centres
Outcomes of regular visits at the
primary health care center shall be
registered through the data
management.
The outcomes of each visit have to
be stored as much as possible in a
structured way.
5.4.3 Conclusion
REACTION is based on a service oriented architecture and will be deployed in a distributed manner. Thus, there will be a need to exchange and synchronize the basic data structures. Therefore we recommend that they are expressed using an XML format and vocabulary.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 36 of 85 DATE 2010-08-31
5.5 Data Semantics
The section deals with the requirements on the interpretation and understanding of the clinical data generated and maintained within the REACTION platform.
5.5.1 Introduction
The complex management of data, information and knowledge is an essential part of the REACTION system. The connection of these three entities can be describes as following: information is transformed from raw data by interpretation or data processing. Knowledge can be derived from the information by learning and reasoning. The prior knowledge influences the whole process, for instance it contains the models for interpretation (see Figure 3). Moreover, inference methods can be used to generate new information from existing information by the use of available knowledge.
The proper definition of the required data, information and knowledge and the necessary transformations is an important step of the design of the system. An initial set was derived from the user requirements and inserted into the technical requirements. As a consequence of the evolutionary design method, the improvement of the requirements might affect these needs as well.
Figure 3: From data to knowledge
Terminology is the system of terms in a given domain. It can ensure that each actor understands the same concept on a certain term. The terminology management includes the maintenance of the taxonomy. If an external terminology is used, it must be regularly updated to the newest version. Suitable candidates for an external terminology can be the Systematized Nomenclature of Medicine -- Clinical Terms (SNOMED) or the Unified Medical Language System (UMLS). If a custom terminology is used, its consistency must be checked and ambiguous elements must be corrected. Requirements concerning semantics needs of the REACTION data management model are summarized blow.
5.5.2 List of Requirements
Key Summary Rationale Fit Criterion
RDMM-29 Definition of a common
ontology to refer to
data, metadata,
interfaces and models
A common ontology facilitates
components integration and maintain
a common language among the
technical people and stakeholders.
All logical entities in software
components should correspond to
terms from the ontology (or to a
published source which justifies
their introduction).
RDMM-37 Semantics based data
management
The monitoring and other data need
to be properly annotated with
ontological descriptions.
Relevant entries in the
REACTION’s databases are
annotated with semantic
concepts.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 37 of 85 DATE 2010-08-31
RDMM-38 Monitoring scheme Individual monitoring scheme for
each patient must be defined and
stored. This describes what
parameters and how often they
should be measured.
An individual monitoring scheme
can be defined for each patient.
RDMM-40 Set of event rules Event rules define the criterions of
different events. Events are detected
based on these rules. Personalization
is possible through the use of
individual thresholds and other
parameters.
Event rules can be defined and
stored.
RDMM-41 Set of action rules Action rules define what should be
done if an event occurs, e.g. who
should be notified and how.
Action rules can be defined and
stored.
RDMM-43 Models and rules for
insulin dose prediction
(inpatient)
A physiologic model and calculation
rules/algorithm must be stored for
insulin dosing support based on
clinical protocols.
Necessary models and rules are
defined and stored.
RDMM-44 Risk assessment models
and rules
Models and rules must be defined to
determine personal risks.
Models and rules for risk
assessment are present.
RDMM-46 Health status model The health status model serves as a
generic prototype for Personal Health
Status Profiles, i.e. defines its data
content. This helps to define personal
models (profiles), which permit the
personalised disease management.
A health status model is present.
RDMM-47 Case generation From the data of individual patients, a
depersonalized case description is
built which will be put in the case
base.
Cases can be generated.
RDMM-49 Personalized care plan A personalized care plan must be
defined (and updated if necessary) for
each patient. It includes disease
management, risk management and
lifestyle plan. Personalization
methods must be defined.
Care plan can be personalized.
RDMM-50 Knowledge Discovery
from unstructured
clinical text information
EPRs often contain unstructured text
information. In order to use this
information for decision support or
diabetes management the
information has be pre-processed.
NLP-technologies to find relevant
information for REACTION
applications from these data bases
(annotation of text information: e.g.
anamnesis information, co-
morbidities, medical history) can be a
useful tool.
REACTION provides a knowledge
discovery module to process
unstructured information and
store this information in the data
storage for further processing.
RDMM-59 Medical knowledge base Contains the relevant medical
knowledge or is able to connect to
external sources, e.g. evidences, drug
information etc.
A medical knowledge base is built.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 38 of 85 DATE 2010-08-31
RDMM-64 Context management
for clinical (lab) values.
Contextualization of measured values
(e.g. blood glucose values) is
important in order to support
REACTION applications like decision
support. For example pre- or post-
meal glucose values have very
different meanings for treatment.
Therefore the data management
model has to provide context
management.
The data management model
support context management
functionality for the inpatient
prototype application.
RDMM-70 Alert / notification
messages should be
short enough in order to
be delivered as SMS
messages if necessary
User’s terminal mobile device will be
likely be used as a GSM mobile phone.
Considering the advantages of Short
Message Service (fast delivery,
provides an alternative data path
when an Internet connection is not
available etc) the time critical
messages for the patients should be
able to be forwarded as SMS
messages.
Functional tests when user is away
from broadband connection.
RDMM-79 Computer interpretable
guidelines
Evidence based guidelines as
important constituents of the
knowledge base must be encoded in a
computer-interpretable way for
decision support.
Guidelines are encoded.
RDMM-81 Self-management and
lifestyle support
Support of the patients’ self-
management by lifestyle (diet,
exercise etc.) advices, therapy
advices, health status assessment.
Self-management is supported.
RDMM-83 Display of acquired
measurements (values,
time, context (if
available))
Provide immediate and consistent (if
possible also contextualized)
information to the patient.
The user interface on the mobile
device shall have this
functionality.
RDMM-85 Content formatter A formatter for converting the
acquired data to useful information
for the patient shall be available.
Use a standard format or a
verification mechanism.
RDMM-96 Electronic fever/sugar
chart
Currently medical history, general
health status, actual status, nutrition
and associated conditions, planned
examinations & treatments,
interaction with other medication,
blood glucose measurements, dose
type and timing of insulin or OAD are
stored in a paper-based fever/sugar
chart. The same information should
be available in an electronic
fever/sugar chart which can be
accessed and shared by several users
at the same time.
In the design of the data
management the electronic
fever/sugar chart (or the
possibility to compose it from the
stored data) has to be present. Its
access must be multi-user. The
fever/sugar chart has to be
initialized at the patient
enrolment and updated at any
data acquisition.
RDMM-97 Contextualization of
measurements
The availability of all measurements
(and mainly blood glucose levels) shall
be accompanied also by the context
of the measurements.
Measurements before any usage
have to be contextualized.
RDMM-110 Context of observations The middleware of the REACTION
platform should support context
management for observed values.
The REACTION platform supports
context management on the client
side.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 39 of 85 DATE 2010-08-31
RDMM-111 Low-level data fusion The REACTION platform should
support low-level data fusion in order
to interpret measurements occurring
in PAN. The Data Fusion needs to take
place close to the patient/user.
Low-level data fusion will be
available for the REACTION
platform (middleware).
RDMM-112 High-level data fusion Besides low-level data fusion on the
client side a high-level data fusion
should be available for the REACTION
platform. The high-level data-fusion
should provide the integration of
external gathered information to the
REACTION platform data structure
and the fusion of REACTION-internal
processed data.
High-level data fusion functionality
will be available for the REACTION
hosting server.
RDMM-124 RDMM-35
Visualization of current
"insulin on board" and
"carbohydrates on
board"
As part of electronic decision support
the current "insulin on board" and
"carbohydrates on board" should be
presented to the physicians and
nurses.
Methods/Functions:
- trend information
- active profile of insulin on board
(using physiological models)
Inpatient prototype provides
visualization of current "insulin on
board" and "carbohydrates on
board" for decision support.
RDMM-125 Context sensitive
interface
"Best guesses" for input values and
context-sensitive interface for data
entry to keep efforts required for data
entry as low as possible.
Users are satisfied with user input.
RDMM-131 Consider patient's
preferences, wishes and
decisions
The data set should allow
documentation of patient's
preferences, wishes and decisions.
This information should also be
considered in the evaluation of rules
etc., so that no recommendations
against the will of the patient are
made.
Patient's preferences, wishes and
decisions can be documented and
rules consider this data.
RDMM-132 Management of
referrals to and
responses from other
physicians (via EHR
interface)
Referrals are part of clinical pathways
and treatment plan.
Referrals should be documented and
the recommendation of referrals
should be considered in decision
support rules...
Summary letters and other
"responses" from other healthcare
professionals should be managed. -
Optimal solution would be an
interface to a regional or national EHR
infrastructure (e.g. IHE-XDS) from
where documents can be received.
Referrals can be documented and
are considered in decision
support, summary letters can be
received via an appropriate data
interface.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 40 of 85 DATE 2010-08-31
RDMM-133 Telemonitoring data
should be visualized to
patients and
professionals in a
flexible and performant
way
GPs and nurses as well as patients and
their carers use the telemonitoring
data to get an impression of the
patient status. So telemonitoring
data needs to be visualized in a
flexible way (aggregation level,
combination of parameters ...)
Data has to be handled in a way that
this visualization can be generated
on-demand with good performance.
Data can be visualized flexibly and
with good performance to
professionals
5.5.3 Conclusion
To support the semantic management of data and as a basis for knowledge management, REACTION will exploit semantic technologies, specifically ontologies.
Ontology can be defined as “the formal specification of shared conceptualization”. This means that it describes the concepts and their relationships in a specific domain, facilitating interoperability both for machines and people. Within the REACTION data management it is only possible to define an ontology restricted to concepts related to diabetes and some general metadata, but not a full medical ontology. This limits the possible use of the ontology.
In the REACTION platform patient data is collected from three different sources:
• Measured by medical devices
• Manually entered by the patient or a member of the medical team (e.g. lifestyle data, visit outcomes (symptoms, new co-morbidities, etc.) or measurements which are not automatically transferred)
• Imported from external source. This mainly includes clinical information systems (EPR/HIS)
The data fusion service provides the integration of externally gathered data to the platform data structure. The data structures must be designed in such a way which takes security aspects into consideration and provides acceptable access speed and enables the joint management of associated data.
Methods must be provided to process data and generate calculated data. This process can be also considered as interpretation as it associates meaning to the data thus generates information. Another way of interpretation is the annotation (addition of metadata). These metadata should be terms from the terminology.
To facilitate the automated processing of text (e.g. the patient record), two possible solutions are available. If structured questionnaires are used to generate text, it can be easily interpreted. This solution is rather inflexible as the questionnaires must be altered when the demands change. The second option is the use of a semantic interpreter which is able to process natural language text. It is a more flexible although more complex technology. An ontology is an important component of a natural language processing system.
A diabetes knowledge base must be built to provide advanced disease management and decision support functions. It may contain the following elements:
• treatment algorithms and protocols
• guidelines represented in a computable way
• physiologic models (e.g. to calculate insulin dose)
• lifestyle models including the possible physiologic consequences
• risk models (take genetics, physiology, lifestyle, social environment into account)
• other schemes and algorithms (e.g. blood glucose patterns, if-then rules)
The knowledge elements must be expressed with terms from the terminology. To be consistent, every change and update must use the same terms. An ontology is an important technological component to perform searches in the knowledge base, e.g. to highlight the relevant parts of the guidelines.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 41 of 85 DATE 2010-08-31
The necessary inference methods apply the above described knowledge to the information known about the patient in order to draw conclusions and provide advices. Methods must be designed to evaluate the rules, apply the models and execute the guidelines.
Several representation formats exist which can be used to encode the necessary information and knowledge. The most appropriate ones will be selected and described together with other relevant details in the deliverable D4-2 Initial data structures, taxonomies and ontologies.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 42 of 85 DATE 2010-08-31
5.6 Data Security
This section analyses protection, privacy and security issues of the REACTION data management model.
5.6.1 Introduction
Privacy and security are especially important issues when it comes to sensitive personal information, such as a patient’s medical record. Because of this, some patients may at first feel that having their medical records accessible in a computer network puts their health and privacy at a greater risk than having their paper file stored in a cabinet. In principle, the privacy and security threats for electronic health records are not new and are similar to those for paper records: files could be lost, stolen, disclosed, manipulated, etc. At first sight, it might look as if it is harder to acquire a medical file from a filing cabinet, as this requires physical access and medical personnel might be alerted by a stranger sifting through a cabinet full of medical files. However, privacy and security can be achieved in an electronic health record system – and with a higher level of protection. Under normal circumstances, access to an EHR system, like in the real-world example before, would never be given to strangers but only to authorised persons which are known to the system, e.g., medical personnel. In addition, electronic access control can be achieved on a much finer scale. First, anyone seeking access to the system can be asked to identify and authenticate themselves before any system resource would be made available. Second, persons which have been given access to the system can be grouped and assigned to specific roles which give them only specific access rights, or even none at all. For instance, there could be one group for administrative personnel and another for medical personnel, such that administrative personnel would not have access to the patient’s health data but only to details such as name, address, and health insurance number. The medical group could also be further subdivided into, say, doctors and nurses, such that doctors would be allowed to fill out forms for diagnoses while nurses would only be allowed to read but not allowed to change them. Of course, all this is common behaviour in doctors’ surgeries and clinics but it is largely ‘enforced’ by ethical and social norms. By introducing digital identities, role-based access control, and authentication mechanisms, it is possible to achieve a technical enforcement of these norms which can provide a higher level of protection. In addition, even in the event that someone manages to gain unauthorised access to an EHR, applying appropriate encryption mechanisms to such data can make it practically useless for the intruder as he/she would be unable to decrypt the data and hence could not learn anything from it.
The privacy aspect of (electronic) medical data is often overlooked, as it is commonly assumed that patients fully trust their doctors in almost every aspect. However, one thing that may change with an EHR is that it might not solely be managed by the doctor that the patient knows and trusts but it might be distributed over several management systems. In such a situation, it might be unclear to the patient who stores and processes which of her medical data and where. Legally speaking, the patient has the right to learn all this and often has to be asked for his/her consent before data is transmitted and processed. However, such requests could be equally confusing to the patients, if they are constantly informed about data transfers and asked for consents. Thus, patients must also be aided in the management of consents and other privacy preferences because otherwise they might be overwhelmed by notifications and requests for consents which ultimately may hinder them to exercise their privacy rights. On the data processor’s side, the existence of a patient’s consent for the processing at hand must be ensured before the data can be processed. Thus, data processors would also need help in managing consents, as they need to request them if they do not yet have one. If they have one, they must be able to decide whether the consent covers the intended processing. Also, it should not be overlooked that consents might be revoked by patients, which processors must take into account. In the case of a revoked consent, any future processing of the data covered by the former consent would not be permitted anymore. The following section lists several requirements which should help to ensure that the patients’ privacy and security expectations are met.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 43 of 85 DATE 2010-08-31
5.6.2 List of Requirements
Key Summary Rationale Fit Criterion
RDMM-4 Sensor devices (PAN/BAN
devices) and receiving
devices (AHDs) MUST be
paired to ensure entity
authentication.
Without any authentication, sensors
may send data to unintended
receivers, which might become a
privacy problem, or AHDs may receive
measurements from devices which
are not the patient's, which might
become a security problem and
eventually a health problem if the
patient receives the wrong treatment
due to 'false' measurements.
Some kind of 'pairing
mechanism' or entity
authentication MUST be used
before any sensor data is
transmitted or received.
RDMM-5 Authentication and integrity
of transmitted
measurements MUST be
ensured.
Without any data authentication, any
measurement might be sent to the
AHD without the AHD being able to
distinguish between measurements
from associated sensors and others.
Also, if the measurements could be
undetectably changed during
transport, intentionally or
unintentionally, this may have ill-
effects on the patient's health
because she may receive the wrong
treatment due to 'false'
measurements.
Mechanisms to ensure data
integrity and entity
authentication MUST be used
for communication between
sensors and AHDs.
RDMM-6 Confidentiality of
transmitted measurements
SHOULD be ensured.
Without any mechanism providing
confidentiality, measurements sent
from sensors might be overheard by
third parties. This circumstance is
alleviated a bit by the fact that
sensors usually have a limited
transmission range but active
eavesdroppers may still use, say,
antennas powerful enough to catch
the signal.
A mechanism to ensure data
confidentiality SHOULD be
used whenever measurements
are sent from the sensor to the
AHD.
RDMM-7 Before transmitting any
personal data, the patient's
consent MUST be given. If
no consent was given yet,
the data MUST NOT be
sent.
Privacy laws require that data
subjects have to consent to the
transmission and processing of their
data. Without consent, transmission
and processing of personal data is not
permitted by law.
A 'watchdog' component must
be in place that supervises the
transmission of personal data
and takes action if data to be
transmitted is not covered by
the subject's consent.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 44 of 85 DATE 2010-08-31
RDMM-8 If data was not transmitted
for a lack of consent, the
patient or her doctor (in
case of a client without
display and input
capabilities) MUST be
notified, e.g., through some
pop-up or a notice in some
message field.
Privacy laws require that data
subjects have to consent to the
transmission and processing of their
data. If a new data item is to be
transferred which was not foreseen in
the initial consent, the subject has to
give a 'new' consent before the new
data item can be transferred and
subsequently processed. If the
subject's AHD has a display and input
capabilities, the AHD may directly ask
the subject for a new consent -- of
course, the subject may also decline
the request.
If the AHD is an appliance without
display, the transmission must include
some kind of notice to inform the
requesting party, usually the patient's
doctor, that some data item was not
transmitted and that the subject
should be asked for an extended
consent.
A notification mechanism for
insufficient consents must be
established for AHDs with and
without display.
RDMM-9 A consent MUST NOT be
considered valid if the
patient was not involved in
the decision.
If it cannot be verified that a consent
was produced by or with the help of
the affected data subject the
'expressed will' of the data subject is
doubtful. Hence, no processing should
be done as it is unclear that the data
subject allowed it.
A mechanism is available that
allows to verify (or infer) that a
given consent was the data
subject's own decision.
RDMM-10 If a consent was given, the
patient's involvement in the
decision MUST be verifiable
by the REACTION Hosting
Client, especially if the
consent was given
remotely, e.g., at the
doctor's surgery.
Consents must be expressed by the
data subject such that a third party,
e.g., an AHD, can verify that the
consent was actually given by the
data subject herself -- this is especially
relevant when the consent was given
at the doctor's surgery and afterwards
pushed back to the patient's AHD.
Otherwise, anyone could produce a
'suitable' consent in the data subject's
name.
Genuineness of a consent can
be verified.
RDMM-11 Data MUST NOT processed
at the REACTION Device
Hosting Server if no consent
is available and verifiable.
If patient data is to be processed at
the REACTION Device Hosting Server,
the server's provider must take the
necessary steps to ensure that such a
processing is permitted by the
patient.
A 'watchdog' component must
be in place that supervises the
processing of patient data and
takes action if data to be
processed is not covered by
the patient's consent.
RDMM-12 Communication between
the REACTION Hosting
Client and the REACTION
Device Hosting Server MUST
be authentic (entity
authentication), with
integrity, and confidential.
It must be assumed that data
transmission from the REACTION
Hosting Client to the REACTION
Device Hosting Server and vice versa
takes place over an insecure channel,
i.e., data might be overheard or
tampered with. Since personal data is
to be transmitted it MUST be ensured
that the communication channel is
authentic, with integrity, and
confidential.
Availability of mechanisms to
provide communication
channels with authenticity,
integrity, and confidentiality.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 45 of 85 DATE 2010-08-31
RDMM-13 It MUST be possible to
revoke consent - data
already stored MUST NOT
be processed any further.
A patient must have the option to
decide whether personal data is
processed or not at any time. If the
patient once gave her consent it must
still be possible for the patient to
revoke her consent, which means that
any further processing of the affected
data is forbidden. Also, if a patient
revoked her consent the existing data
may not necessarily be deleted,
however, it MUST be excluded from
any further processing.
Availability of mechanisms and
procedures to enable consent
revocation.
RDMM-14 Communication between
the REACTION Device
Hosting Server and the
EPR/EHR System MUST be
authentic (entity
authentication), with
integrity, and confidential.
It must be assumed that data
transmission from the REACTION
Device Hosting Server to the EPR/EHR
System and vice versa takes place
over an insecure channel, i.e., data
might be overheard or tampered
with. Since personal data is to be
transmitted it MUST be ensured that
the communication channel is
authentic, with integrity, and
confidential.
Availability of mechanisms to
provide communication
channels with authenticity,
integrity, and confidentiality.
RDMM-15 Data/messages exchanged
between the REACTION
Host Client and the
REACTION Device Hosting
Server MUST be authentic
(message authentication),
with integrity, and
confidential.
The security of messages transferred
between the REACTION Host Client
and the REACTION Device Hosting
Server must be ensured even _after_
the message was received - this is
true even if the message was received
over a secure communication
channel. To guarantee this, the
messages themselves MUST be self-
contained with respect to
authenticity, integrity, and
confidentiality.
Availability of mechanisms to
provide data authenticity,
integrity, and confidentiality
RDMM-16 Data/messages exchanged
between the REACTION
Device Hosting Server and
the EPR/EHR System
SHOULD be authentic
(message authentication),
with integrity, and
confidential.
The security of messages transferred
between the REACTION Device
Hosting Server and the EPR/EHR
System must be ensured even after
the message was received - this is
true even if the message was received
over a secure communication
channel. To guarantee this, the
messages themselves MUST be self-
contained with respect to
authenticity, integrity, and
confidentiality.
Availability of mechanisms to
provide data authenticity,
integrity, and confidentiality
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 46 of 85 DATE 2010-08-31
RDMM-17 Data/messages exchanged
between the REACTION
Device Hosting Server and
the GP EPR SHOULD be
authentic (message
authentication), with
integrity, and confidential.
The security of messages transferred
between the REACTION Device
Hosting Server and the GP EPR must
be ensured even after the message
was received - this is true even if the
message was received over a secure
communication channel. To
guarantee this, the messages
themselves MUST be self-contained
with respect to authenticity, integrity,
and confidentiality.
Availability of mechanisms to
provide data authenticity,
integrity, and confidentiality
RDMM-18 Communication between
the REACTION Device
Hosting Server and the GP
EPR MUST be authentic
(entity authentication), with
integrity, and confidential.
It must be assumed that data
transmission from the REACTION
Device Hosting Server to the GP EPR
and vice versa takes place over an
insecure channel, i.e., data might be
overheard or tampered with. Since
personal data is to be transmitted it
MUST be ensured that the
communication channel is authentic,
with integrity, and confidential.
Availability of mechanisms to
provide communication
channels with authenticity,
integrity, and confidentiality.
RDMM-19 Communication between
the REACTION Device
Hosting Server and the
patient's/GP's web browser
MUST be authentic (entity
authentication), with
integrity, and confidential.
It must be assumed that data
transmission from the REACTION
Device Hosting Server to the
patient's/GP's web browser and vice
versa takes place over an insecure
channel, i.e., data might be overheard
or tampered with. Since personal data
is to be transmitted it MUST be
ensured that the communication
channel is authentic, with integrity,
and confidential.
Availability of mechanisms to
provide communication
channels with authenticity,
integrity, and confidentiality.
RDMM-20 Roles MUST be defined for
stakeholders of the
REACTION platform, e.g.,
doctor, nurse, patient,
informal carer,
administrative personnel
etc.
Each person in the REACTION
platform has the right to perform a
certain set of actions. In order to
simplify the administration of these
rights, each person is assigned to a
role and roles are assigned to
permissible actions. The advantage of
this approach is that it is easier to
manage the rights of a role than
managing individual rights for each
person.
Roles are defined for every
actor from the REACTION use
cases.
RDMM-21 Every person represented in
the REACTION platform
MUST be assigned to one or
more roles.
In order to interact with the
REACTION platform, persons need
certain rights. As rights are associated
with roles, persons MUST have at
least one role to interact with the
REACTION platform.
Each person is assigned to at
least one role.
RDMM-22 Each role MUST be assigned
to a set of permissible
actions.
Since some actions are reserved for
specific roles it has to be decided
which actions are permissible for
which role.
According to the roles' needs,
each role is assigned to a set of
appropriate permissions.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 47 of 85 DATE 2010-08-31
RDMM-23 Each person MAY only
perform actions permitted
by her role.
Before a requested action is
performed, a control mechanism has
to check whether the requested
action is part of the requester's set of
permissible actions according to its
role.
Availability of a control
mechanism which decides
whether a requested action
may be granted or denied
according to the requester's
role.
RDMM-24 Each entity in the REACTION
platform MUST be
representable by a digital
identity.
In the REACTION platform, entities
must be uniquely identifiable and
recognisable in order to allow
repeated communication, referrals,
accountability of actions, exclusion of
ill-behaving entities, etc.
Availability of a digital identity
mechanism.
RDMM-25 Digital identities for the
REACTION platform MUST
only be issued or revoked
by trusted (third) parties,
e.g., a certification authority
(CA).
Without a trusted party (TP), anyone
could produce its own digital identity
and someone relying on such an
identity would have to trust that the
claimed identity is genuine. By
incorporating a TP, relying parties
trust that the TP ensures that its
issued digital identities are genuine.
This makes life easier for relying
parties as they only have to establish
a single trust relationship (with the
TP) as opposed to having a multitude
of trust relationships with others. The
same goes for parties that had been
excluded from the REACTION
platform, as each relying party would
have to determine by itself if another
party is still part of the REACTION
platform or not. In case of a trusted
party, the relying part could simply
query the TP if some identity is still
valid or had been revoked, e.g.,
because its owner left the platform.
Availability of a party which is
trusted to orderly issue and
revoke digital identities.
RDMM-91 Privacy enhancing
technology
Protect the privacy of users’
personally identifiable information
(PII) and further more personal data.
Each measurement in each
transmission channel shall be
separated from the patient
data and association between
measurements and patient
shall not be possible for
whoever can intercept the
measurements.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 48 of 85 DATE 2010-08-31
RDMM-118 Privacy Enforcement Point A component that could be added to
the client side would be some kind of
'Privacy Enforcement Point'. Such a
component could be examining
outgoing data for information that
the client did not authorize to be sent,
yet. That is, the component would
match the client's consents (with
respect to the processing of her data)
with the kind of information from the
outgoing message and, possibly, delay
the transmission of certain
information which the client has not
decided on.
The component could stay hidden in
other components for the time being,
such as the Network Manager on the
client side. The Privacy Enforcement
Point should perform as a counterpart
of the Consent Manager at the
REACTION Device Hosting Server.
Privacy Enforcement Point is
available for the REACTION
client side.
RDMM-120 Telemonitoring
profile/consent manager
This module should provide security
mechanism for data stored in the
REACTION platform. Patients have to
acknowledge that personal data
gathered from them can be stored
and transmitted within the technical
infrastructure of REACTION.
Therefore the patient has to sign a
consent form and the information
about this should be stored within the
system. It should be possible to
exclude several personal information
from storage/transmission.
This manager could be queried, e.g.
by the data fusion component (or any
other component that processes
personal patient
data) before anything is processed in
order to determine if the processing
was permitted by the patient. Such
permission would be expressed by
way of consent.
Telemonitoring
profile/consent manager will
be technically implemented
into the REACTION platform.
5.6.3 Conclusion
The REACTION platform is organised in a decentralised manner, such that personal, medical information is transmitted and shared by several parties. Therefore, it is necessary that such data is transmitted, managed, and processed in a secure, trusted, and privacy-preserving way. This means that confidentiality has to be guaranteed in order to allow medical devices to upload measurements (e.g. from patients’ to their doctor’s PC without anyone else being able to learn about these measurements. It also means that authenticity of senders and recipients of medical data must be ensured.
For instance, the patient’s client device must be able to verify that the medical data is uploaded to the PC of the intended doctor or the doctor’s device must be able to correctly identify the patient, thus enabling it to add the received data to the ‘right’ EHR. In addition, data may only be added to the EHR if it was not
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 49 of 85 DATE 2010-08-31
tampered with during its transmission or subsequent processing, i.e., the data’s integrity must be verifiable and the verification must be carried out before the data is added to the EHR. Access to such personal data may naturally be given to authorised entities only. If this is not the case, stored patient data could be easily manipulated which could have detrimental effects on the patient’s health and would erode the trust in electronic health care.
Privacy laws also play a central role in the management of personal, medical data, as often the patient’s consent must be sought before any data processing can take place. Consent, whether in paper or electronic form, must be given by the patient him/herself which, of course, should be verifiable. However, the lack of consent might constrain or even prohibit the treatment of a patient as it might not be possible to make a proper diagnosis due to missing or inaccessible data. Therefore technical means for detecting and informing patients and medical personnel about missing consents have to be considered as well.
The requirements can be assigned to functions and components of the data management model in the following way:
• (Sensor / mobile device) PAN/BAN security (RDMM-4, -5, -6)
• Data/message security (RDMM-15, -16, -17)
• Communication security (RDMM-18, -19, -12, -14)
• Access control (RDMM-20, -21, -22, -23)
• Digital identities (RDMM-24, -25)
• Privacy (RDMM-7, -8, -9, -10, -11, -13, -120)
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 50 of 85 DATE 2010-08-31
6. REACTION Prototypes: Use-Cases for Applications
This section presents use-cases for the inpatient and the primary care prototypes identified in the initial user requirements of D2-5. These use-cases enable technical partners to obtain a better understanding of the main tasks of the REACTION prototypes, including how the system components interact with users. Moreover, this chapter relates technical requirements for the REACTION data management model to (1) the inpatient glucose control and (2) the primary care disease management application. Therefore, for each of the prototypes, typical use-cases have been designed and use-case diagrams have been created for visualization. Requirements related to each prototype have been assigned to the use-cases and finally the implications for the REACTION platform technology have been described.
6.1 Inpatient Glucose Control
6.1.1 Introduction
In-hospital hyperglycaemia has been found to be an important marker of poor clinical outcome and mortality among diabetic patients. The in-hospital care application domain of the REACTION platform will feature a range of services aiming at Safe Glycaemic Control of diabetic patients using an individual target level depending on the history and actual state of the patient. In order to understand the clinical needs in the inpatient ward, a workshop at the inpatient site in Graz was held. The outcome of this workshop has been documented in D2-1.
In the general ward, a REACTION application must monitor a range of parameters including blood glucose, nutritional intake as well as measures of insulin sensitivity. The data will be contextualised in the Data Management component and mathematical algorithms will be used to calculate the required insulin doses. Results will be delivered to dedicated diabetes experts specialised in glycaemic control (usually located in a specialist diabetes centre) for verification and evaluation. Their on-line appraisal will be fed back to the physicians and nurses at the point of care in the patients ward.For the implementation of the new REACTION application, hospital systems will need to be adapted and hospital protocols across wards for administration and monitoring of blood glucose levels and insulin infusions will be required.
Daily insulin treatment follows the natural workflows of humans based on three daily meals and a prolonged cycle of rest. The three meals are distributed over morning, mid day and evening. During and after meal intake the blood glucose level rises due to carbohydrates. In non-diabetic patients, this is compensated with the release of insulin from the pancreas resulting in a well controlled, steady glucose level. In diabetic patients, or patients with temporary insulin resistance, the flow of insulin is either reduced or non-existing and has to be compensated with manual injection of insulin.
The main outcomes of D2-1 indicated following mid-term improvements through the REACTION inpatient platform for managing in-hospital diabetes patients:
• Automated patient identification to avoid mistakes
• Performing measurements - Active alarm system, reminder to perform measurements
• Decision making – Electronic decision support system - standardised instructions and decisions
• Data handling - Automated transfer of data to patient record and hospital information system
• Documentation - Electronic paperless data records, centrally managed data repositories, different modes of visualisation with relevant parameters for decision support
Figure 4 shows the use-case diagram implementing the most important features for the inpatient insulin dosing prototype. Following main components can be identified:
Administer Glycaemic Management
In a first step the health status of the patient will be determined by the physician. The health status is based on data that will be extracted from existing medical data systems (e.g. the hospital information system, laboratory information system) or entered manually by the nurse. Data manually entered could include, for example, nutrition, glucose injection performed, or pre-existing conditions. If glucose data is needed immediately, glucose values can be entered manually from the POCT device by the nurse. The gathered data will be stored in a centrally managed system and relevant information will be presented to the main users (nurse, physician) via a paperless visualization system. For example the system can
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 51 of 85 DATE 2010-08-31
support the nurse by presenting the most important information in the ward summary for all admitted diabetic patients. The nurse will be reminded to measure blood glucose or warnings of hyper- or hyperglycaemia will be signalled by the system. The administration of glycaemic management will be part of the electronic decision support system (eDSS) for inpatient insulin dosing.
Ward Round
The information gathered by glycaemic management will be displayed on a mobile device and, most importantly, the system will suggest the required insulin dose using an electronic decision support algorithm at the ward round, available to the physician. The suggested insulin dose has to be approved or declined (an alternative therapy has to be entered) by the responsible carer. In this way the physician is able to incorporate suggestions for insulin dose and information like glucose level into his or her overall decision-making process. All decisions, whether suggested by the system or the physician, will be stored in the electronic decision support system (eDSS).
Patient Data Handling
In addition to medical data handling for decision making, administrative non-clinical data must also be handled by the overall system. Therefore, interfaces to the hospital information system (incl. laboratory information systems) have to be implemented.
Retrospective Quality Analysis
The tight (glycaemic) control of the diabetic patient on the ward enables retrospective quality analysis for improvement of treatment quality to be performed. Information obtained from decision-making and the glycaemic management can be used to further enhance the algorithm of the electronic decision support system.
6.1.2 Use Case Diagram for Inpatient Glucose Control
Fig
ure
4:
Use-C
ase D
iagra
m f
or
Inpatient
Glu
cose C
ontr
ol
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
53 o
f 85
DA
TE
2010-0
8-3
1
6.1.3 List of Requirements
Ke
y
Re
qu
ire
me
nt
sub
typ
e
Su
mm
ary
R
ati
on
ale
F
it C
rite
rio
n
Lin
k t
o U
se-C
ase
RD
MM
-3
Da
ta i
nte
rfa
ce
Inte
rfa
ce t
o p
ati
en
t
de
mo
gra
ph
ic r
eg
iste
r
In o
rde
r to
im
po
rt d
em
og
rap
hic
da
ta f
rom
th
e p
ati
en
t
de
mo
gra
ph
ic r
eg
iste
r h
as
to b
e
imp
ort
ed
fro
m t
he
HIS
. A
sta
nd
ard
ize
d i
nte
rfa
ce e
.g.
HL7
ha
s to
be
use
d f
or
da
ta
inte
rch
an
ge
.
Re
qu
ire
d d
ata
fie
lds
are
:
- u
niq
ue
PID
- n
am
e
- a
ge
(d
ata
of
bir
th)
- se
x
- a
dd
ress
Sta
nd
ard
ize
d i
nte
rfa
ce (
HL7
) to
pa
tie
nt
de
mo
gra
ph
ic r
eg
iste
r is
ava
ila
ble
fo
r th
e i
np
ati
en
t p
ilo
t
ap
pli
cati
on
Pa
tie
nt
ide
nti
fica
tio
n,
Pa
tie
nt
ad
min
istr
ati
on
RD
MM
-26
D
ata
in
terf
ace
In
terf
ace
to
La
b
Info
rma
tio
n S
yst
em
(LI
S)
for
glu
cose
da
ta i
mp
ort
In o
rde
r to
pe
rfo
rm d
eci
sio
n
sup
po
rt t
he
blo
od
glu
cose
va
lue
ha
s to
be
im
po
rte
d f
rom
th
e L
ab
Info
rma
tio
n S
yst
em
(LI
S).
A
sta
nd
ard
ize
d i
nte
rfa
ce f
rom
inp
ati
en
t p
ilo
t a
pp
lica
tio
n t
o t
he
LIS
ha
s to
be
de
fin
ed
. H
L7 w
ou
ld
be
a s
uit
ab
le s
tan
da
rd.
Sta
nd
ard
ize
d I
nte
rfa
ce (
e.g
.
ba
sed
on
HL7
) to
La
b
Info
rma
tio
n S
yst
em
(LI
S)
for
glu
cose
da
ta i
mp
ort
.
Glu
cose
da
ta e
ntr
y
RD
MM
-28
D
ata
in
terf
ace
In
terf
ace
to
Ho
spit
al
Info
rma
tio
n S
yst
em
fo
r
clin
ica
l d
ata
im
po
rt/e
xpo
rt
In o
rde
r to
exc
ha
ng
e c
lin
ica
l d
ata
be
twe
en
in
pa
tie
nt
pil
ot
ap
pli
cati
on
an
d H
osp
ita
l
info
rma
tio
n S
yst
em
(H
IS)
an
inte
rfa
ce b
ase
d o
n H
L7 h
as
to b
e
pro
vid
ed
.
Sta
nd
ard
ize
d I
nte
rfa
ce (
HL7
) to
HIS
/ E
PR
to
exc
ha
ng
e c
lin
ica
l
da
ta.
Init
ial
pa
tie
nt
he
alt
h
sta
tus
da
ta e
ntr
y
RD
MM
-34
D
ata
in
terf
ace
In
terf
ace
fo
r u
ser
inp
uts
fro
m p
ort
ab
le c
om
pu
ter
in
ord
er
to s
tore
da
ta i
n
inp
ati
en
t d
ata
sto
rag
e.
Fo
r th
e i
np
ati
en
t p
roto
typ
e u
ser
inp
ut
sho
uld
be
po
ssib
le.
Th
e u
ser
da
ta s
ho
uld
be
sto
red
in
th
e d
ata
sto
rag
e.
Use
r in
pu
t ca
n b
e s
tore
d i
n t
he
inp
ati
en
t p
roto
typ
e s
tora
ge
fo
r
furt
he
r p
roce
ssin
g.
Ma
nu
al
da
ta e
ntr
y
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
54 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-35
D
ata
in
terf
ace
(W
eb
) S
erv
ice
to
pre
sen
t
de
cisi
on
su
pp
ort
fo
r
glu
cose
co
ntr
ol
to c
lin
icia
ns
Aft
er
pro
cess
ing
of
da
ta b
y t
he
glu
cose
pre
dic
tio
n a
lgo
rith
m,
the
resu
lts
sho
uld
be
pre
sen
ted
by
th
e
syst
em
to
th
e p
hy
sici
an
. T
he
ph
ysi
cia
n c
an
use
th
e r
esu
lt f
or
de
cisi
on
su
pp
ort
. T
he
se
rvic
e u
ses
da
ta s
tore
d i
n t
he
da
ta s
tora
ge
an
d u
ser
ad
dit
ion
al
use
r in
pu
t a
s
inp
ut
for
pro
cess
ing
.
A s
erv
ice
wil
l b
e a
vail
ab
le t
o
sup
po
rt p
hy
sici
an
wit
h g
luco
se
con
tro
l o
f p
ati
en
ts.
Su
gg
est
In
suli
n D
ose
RD
MM
-36
D
ata
in
terf
ace
In
terf
ace
fo
r tr
an
smis
sio
n
of
glu
cose
va
lue
s fr
om
PO
CT
sy
ste
m t
o i
np
ati
en
t
pro
toty
pe
As
de
cisi
on
su
pp
ort
is
a t
ime
crit
ica
l p
roce
ss d
ata
fro
m t
he
PO
CT
de
vice
sh
ou
ld b
e t
ran
sfe
rre
d
dir
ect
ly (
wit
ho
ut
de
tou
r to
LIS
) to
the
in
pa
tie
nt
pro
toty
pe
in
ord
er
to
spe
ed
up
th
e t
ran
smis
sio
n
pro
cess
. T
he
refo
re a
n i
nte
rfa
ce
ha
s to
be
pro
vid
ed
.
Inte
rfa
ce t
o P
OC
T d
evi
ce i
s
ava
ila
ble
fo
r th
e i
np
ati
en
t
pro
toty
pe
.
Glu
cose
Da
ta E
ntr
y
RD
MM
-12
2
Da
ta i
nte
rfa
ce
Ma
xim
um
de
lay
to
tra
nsf
er
blo
od
glu
cose
va
lue
fro
m
PO
CT
to
in
pa
tie
nt
pro
toty
pe
Up
-to
-da
te g
luco
se v
alu
es
are
ab
solu
tely
ne
cess
ary
fo
r e
lect
ron
ic
de
cisi
on
su
pp
ort
. In
ord
er
to
imp
rov
e u
sab
ilit
y f
or
ph
ysi
cia
ns
the
tra
nsf
er
de
lay
fro
m P
OC
T
de
vice
to
in
pa
tie
nt
serv
er
ap
pli
cati
on
sh
ou
ld b
e m
ax.
3
seco
nd
s. T
he
refo
re t
he
in
terf
ace
ha
s to
be
ap
pro
pri
ate
to
fu
lfil
th
is
con
stra
int.
De
lay
of
blo
od
glu
cose
tra
nsf
er
is m
ax.
3 s
eco
nd
s
Glu
cose
Da
ta E
ntr
y
RD
MM
-12
3
Da
ta i
nte
rfa
ce
Inp
ati
en
t p
roto
typ
e
com
mu
nic
ati
on
wit
h
RE
AC
TIO
N p
latf
orm
Th
e c
urr
en
t d
esi
gn
of
the
in
pa
tie
nt
pro
toty
pe
an
d t
he
pri
ma
ry c
are
pro
toty
pe
do
es
no
t co
nsi
de
r th
e
com
mu
nic
ati
on
be
twe
en
th
ese
two
pro
toty
pe
s (e
.g.
SO
A).
Th
us,
the
da
ta m
od
el
sho
uld
co
nsi
de
r
ho
w t
he
pro
toty
pe
s ca
n b
e
me
rge
d i
n f
utu
re w
ith
in t
he
RE
AC
TIO
N p
latf
orm
. A
da
ta/c
om
mu
nic
ati
on
in
terf
ace
ha
s
to b
e d
efi
ne
d.
Co
mm
un
ica
tio
n a
nd
tra
nsf
er
of
da
ta b
etw
ee
n i
np
ati
en
t a
nd
ou
tpa
tie
nt
pro
toty
pe
s a
re
po
ssib
le.
--
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
55 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-39
D
ata
so
urc
e
Da
ta f
ield
s fo
r th
e i
np
ati
en
t
glu
cose
co
ntr
ol
pro
toty
pe
(eD
SS
).
Fo
llo
win
g d
ata
fie
lds
sho
uld
be
pro
vid
ed
:
- a
dm
inis
tra
tive
da
ta (
pa
tie
nt
na
me
, a
dd
ress
, P
ID,
wa
rd,
ho
spit
al
be
d,
ph
ysi
cia
n(s
) in
ch
arg
e,
nu
rse
(s)
in c
ha
rge
)
- d
em
og
rap
hic
da
ta
(ag
e,
sex,
da
te o
f b
irth
)
- m
ed
ica
l h
isto
ry
(ty
pe
of
dia
be
tes,
me
dic
ati
on
, co
-
mo
rbid
itie
s, f
orm
er
com
pli
cati
on
s,
pre
-exi
stin
g c
on
dit
ion
s)
- a
na
mn
esi
s d
ata
(fe
ver,
in
fect
ion
s, d
iarr
he
a,
vom
itin
g,
hy
po
- h
yp
erg
lyce
mia
)
- la
b d
ata
(glu
cose
le
vel,
HB
A1
c, .
..)
- e
xte
rna
l in
pu
t
(fo
od
in
tak
e,
insu
lin
se
nsi
tiv
ity
, ..
.)
- co
nte
xt d
ata
(tim
e o
f g
luco
se m
ea
sure
me
nt,
wh
at
de
vice
, ..
.)
Re
qu
ire
d d
ata
fie
lds
wil
l b
e
pro
vid
ed
by
da
ta s
tru
ctu
re.
Ad
min
iste
r G
lyca
em
ic
Ma
na
ge
me
nt
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
56 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-78
D
ata
so
urc
e
Cli
nic
al
da
ta t
o b
e s
tore
d i
n
the
In
pa
tie
nt
en
viro
nm
en
t
Th
e d
ata
ma
na
ge
me
nt
sha
ll b
e
de
sig
ne
d i
n o
rde
r to
all
ow
th
e
sto
rag
e o
f th
e c
lin
ica
l d
ata
to
be
reg
iste
red
at
the
pa
tie
nt
en
rolm
en
t a
s w
ell
as
oth
er
clin
ica
l
pa
ram
ete
rs w
hic
h h
av
e t
o b
e
acq
uir
ed
mo
re f
req
ue
ntl
y.
Th
e d
ata
to
be
re
gis
tere
d a
t th
e
pa
tie
nt
en
rolm
en
t a
re:
typ
e o
f
dia
be
tes
(in
suli
n r
eq
uir
em
en
t),
ne
wly
dia
gn
ose
d d
iab
ete
s,
we
igh
t/B
MI/
wa
ist
to h
ip r
ati
o,
Hb
A1
c (u
pd
ate
d),
fe
ve
r, i
nfe
ctio
n,
dia
rrh
oe
a,
vom
itin
g,
hy
po
gly
cae
mia
(la
st 3
da
ys)
an
d
hy
pe
rgly
cae
mia
, li
mit
ed
ren
al/
he
pa
tic
fun
ctio
n,
pa
ncr
ea
s
op
era
tio
n,
co-m
orb
idit
ies,
th
era
py
sch
em
e.
Oth
er
pa
ram
ete
rs h
av
e t
o b
e
me
asu
red
mo
re f
req
ue
ntl
y:
glu
cose
le
ve
l, i
nje
cte
d i
nsu
lin
,
foo
d i
nta
ke
/nu
trit
ion
, e
stim
ati
on
of
insu
lin
Th
e d
ata
ma
na
ge
me
nt
sha
ll
all
ow
th
e i
nse
rtio
n a
nd
th
e
up
da
te o
f a
ll t
he
lis
ted
cli
nic
al
pa
ram
ete
rs.
Ad
min
iste
r G
lyca
em
ic
Ma
na
ge
me
nt
RD
MM
-10
1
Da
ta s
ou
rce
D
rug
ad
min
istr
ati
on
da
ta
(OA
D a
nd
/or
insu
lin
)
Dru
g a
dm
inis
tra
tio
n (
tim
e,
insu
lin
typ
e,
ad
min
istr
ati
on
ty
pe
-IV
or
SC
-, d
osa
ge
an
d o
the
r re
leva
nt
info
rma
tio
n)
ha
s to
be
imm
ed
iate
ly r
eg
iste
red
in
th
e d
ata
ma
na
ge
me
nt
by
th
e a
dm
inis
teri
ng
nu
rse
.
Da
ta o
n d
rug
s a
dm
inis
tere
d h
ave
to b
e s
tore
d i
n t
he
da
ta
ma
na
ge
me
nt
wh
ere
th
ey
ca
n b
e
als
o r
etr
iev
ed
as
pa
rt o
f th
e
feve
r/su
ga
r ch
art
.
Init
ial
pa
tie
nt
he
alt
h
sta
tus
da
ta e
ntr
y;
Ma
nu
al
da
ta e
ntr
y
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
57 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-10
2
Da
ta s
ou
rce
S
pe
cia
l
exa
min
ati
on
s/tr
ea
tme
nts
to b
e r
eg
iste
red
in
fe
ve
r
cha
rt
Fo
r so
me
exa
min
ati
on
s/tr
ea
tme
nts
in
th
e
ho
spit
al
the
pa
tie
nts
ha
ve t
o b
e i
n
a f
ast
ing
an
d/o
r g
lyca
em
ic
con
dit
ion
. In
su
ch c
ase
s tr
ea
tme
nt
mu
st t
he
refo
re b
e a
dju
ste
d t
o t
he
pa
rtic
ula
r n
ee
ds
(e.g
. d
uri
ng
fast
ing
co
nd
itio
ns
the
in
suli
n d
ose
is d
ecr
ea
sed
). H
ow
ev
er
a p
rob
lem
ma
y a
rise
if
the
pa
tie
nt
ha
s to
wa
it
lon
ge
r th
an
exp
ect
ed
du
e t
o
un
fore
see
n d
ela
ys.
Th
is m
ay
re
sult
in g
lyca
em
ic e
xcu
rsio
ns
(hy
pe
r- o
r
hy
po
gly
cae
mia
). T
he
do
se o
f
insu
lin
an
d/o
r O
AD
s w
ill
the
refo
re
ne
ed
to
be
ad
ap
ted
, th
e p
ati
en
t
rece
ive
s so
me
fo
od
in
th
e e
ve
nt
of
hy
po
gly
cae
mia
an
d r
ece
ive
s
insu
lin
by
in
ject
ion
in
th
e e
ven
t o
f
hy
pe
rgly
cae
mia
.
Th
ese
eve
nts
(sp
eci
al
exa
min
ati
on
/tre
atm
en
ts)
ha
ve
to b
e r
eg
iste
red
in
th
e d
ata
ma
na
ge
me
nt
wh
ere
th
ey
ca
n b
e
retr
ieve
d f
or
the
co
mp
osi
tio
n o
f
the
fe
ver/
sug
ar
cha
rt.
Su
gg
est
In
suli
n D
ose
RD
MM
-94
D
ata
so
urc
e
Me
asu
rem
en
ts o
f b
loo
d
glu
cose
an
d i
nsu
lin
inje
ctio
ns
in I
np
ati
en
t
en
viro
nm
en
t
In i
np
ati
en
t e
nvi
ron
me
nt,
th
e
blo
od
glu
cose
le
vel
me
asu
rem
en
ts
are
, in
mo
st c
ase
s, p
erf
orm
ed
by
nu
rse
s w
ith
tre
atm
en
t p
erf
orm
ed
by
cli
nic
ian
s a
nd
/or
nu
rse
s.
Me
asu
rem
en
ts o
f b
loo
d g
luco
se
an
d i
nsu
lin
in
ject
ion
s a
re t
ask
s
pe
rfo
rme
d b
y c
lin
icia
ns
an
d/o
r
nu
rse
s. T
he
y h
ave
to
sto
re t
he
rele
van
t d
ata
in
th
e s
yst
em
or
to
sta
rt t
he
pro
ced
ure
fo
r th
e
sto
rag
e o
f th
e r
ele
van
t d
ata
in
the
sy
ste
m.
Me
asu
re G
luco
se,
(Ma
nu
al)
Glu
cose
Da
ta
En
try
RD
MM
-95
D
ata
so
urc
e
Ba
sic
wo
rkfl
ow
in
In
pa
tie
nt
en
viro
nm
en
t
Th
e b
asi
c w
ork
flo
w i
s b
ase
d o
n
me
asu
rem
en
t o
f b
loo
d g
luco
se
an
d e
valu
ati
on
of
the
ne
cess
ary
insu
lin
(b
olu
s o
r b
asa
l),
ba
sed
als
o
on
ad
dit
ion
al
pa
ram
ete
rs a
nd
insu
lin
ad
min
istr
ati
on
.
Th
ere
sh
ou
ld b
e t
he
po
ssib
ilit
y
of
acq
uir
ing
, st
ori
ng
an
d
retr
ievi
ng
all
th
e i
nfo
rma
tio
n
ge
ne
rate
d d
uri
ng
an
y b
asi
c
wo
rkfl
ow
pe
rfo
rme
d d
uri
ng
an
y
tim
e o
f th
e d
ay
/nig
ht.
Ad
min
iste
r G
lyca
em
ic
Co
ntr
ol
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
58 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-98
D
ata
sto
rag
e
Cli
nic
al
eva
lua
tio
n r
ep
ort
S
up
erv
isio
n o
f g
lyca
em
ia a
nd
ass
oci
ate
d t
rea
tme
nt
is p
erf
orm
ed
on
ce a
da
y.
Th
e c
lin
ica
l e
valu
ati
on
rep
ort
ha
s to
be
pro
du
ced
da
ily
.
Ad
ap
tati
on
of
the
rap
y o
r ch
an
ge
s
of
me
dic
ati
on
s h
as
to b
e
eva
lua
ted
in
clu
din
g b
y
con
sult
ati
on
wit
h t
he
du
ty-
ph
ysi
cia
n.
A d
ail
y c
lin
ica
l e
valu
ati
on
re
po
rt
ha
s to
be
sto
red
an
d a
vail
ab
le i
n
the
In
pa
tie
nt
ap
pli
cati
on
.
Re
tro
spe
ctiv
e Q
ua
lity
An
aly
sis
RD
MM
-99
D
ata
sto
rag
e
Th
era
py
sch
em
e i
n
Inp
ati
en
t e
nvi
ron
me
nt
De
cisi
on
on
th
era
py
ha
s to
be
pe
rfo
rme
d i
mm
ed
iate
ly a
fte
r
pe
rfo
rmin
g a
ny
me
asu
rem
en
ts
ba
sed
als
o o
n p
ati
en
t h
isto
ry a
nd
ass
oci
ate
d p
ara
me
ters
. It
mig
ht
imp
ly c
ha
ng
es
in t
he
th
era
py
sch
em
e.
Th
e p
ha
rma
ceu
tica
l a
nd
no
n-
ph
arm
ace
uti
cal
tre
atm
en
t (o
r
the
rap
y s
che
me
) h
as
to b
e
sto
red
in
th
e d
ata
ma
na
ge
me
nt
an
d c
an
be
mo
dif
ied
du
rin
g a
ny
clin
ica
l e
valu
ati
on
of
the
pa
tie
nt.
It h
as
to b
e i
nit
iali
zed
imm
ed
iate
ly a
fte
r th
e p
ati
en
t
en
rolm
en
t.
Init
ial
pa
tie
nt
he
alt
h
sta
tus
da
ta e
ntr
y;
Ma
nu
al
Da
ta E
ntr
y
RD
MM
-10
7
Da
ta s
tora
ge
O
nto
log
ies
an
d d
ata
ma
na
ge
me
nt
de
sig
ne
d f
or
the
sto
rag
e a
nd
mu
lti-
use
r
ava
ila
bil
ity
of
all
re
leva
nt
info
rma
tio
n,
act
ion
s,
tre
atm
en
ts,
ev
en
ts
Ce
ntr
all
y m
an
ag
ed
da
ta
rep
osi
tori
es
sha
ll b
e d
esi
gn
ed
an
d
imp
lem
en
ted
ab
le t
o s
tore
an
d
dis
pla
y (
mu
lti-
use
r) a
ll t
he
rele
van
t in
form
ati
on
fo
r th
e
dia
be
tic
pa
tie
nt
ma
na
ge
me
nt
in
the
In
pa
tie
nt
en
viro
nm
en
t.
Da
ta i
nse
rtio
n a
nd
/or
up
da
te
an
d d
ata
re
trie
val
for
pa
tie
nts
sha
ll b
e p
oss
ible
in
mu
lti-
use
r
wa
y.
Ma
nu
al
Da
ta E
ntr
y
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
59 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-10
3
Da
ta s
tora
ge
S
tora
ge
of
hy
pe
rgly
cae
mic
or
hy
po
gly
cae
mic
ep
iso
de
s
Re
aso
ns
for
an
y c
ase
s o
f
hy
po
gly
cae
mia
ha
ve t
o b
e
reg
iste
red
(o
verd
osi
ng
of
insu
lin
,
cha
ng
e i
n n
utr
itio
n,
vom
itin
g,
cha
ng
es
in i
nsu
lin
se
nsi
tivi
ty
an
d/o
r re
sist
an
ce,
etc
.) a
nd
ad
eq
ua
te t
rea
tme
nt
ha
s to
be
pro
vid
ed
an
d r
eg
iste
red
. S
ho
uld
the
blo
od
glu
cose
le
vel
rise
ab
ove
a c
ert
ain
th
resh
old
, a
hy
pe
rgly
cae
mic
ep
iso
de
ha
s
occ
urr
ed
. T
he
re
aso
ns
for
such
an
ep
iso
de
ha
ve
to
be
re
gis
tere
d
alo
ng
wit
h e
nsu
ing
ch
an
ge
s in
tre
atm
en
t.
Sp
eci
fic
pro
ced
ure
s h
ave
to
be
pre
sen
t fo
r th
e m
an
ag
em
en
t o
f
hy
pe
rgly
cae
mic
or
hy
po
gly
cae
mic
ep
iso
de
s. T
he
se
pro
ced
ure
s sh
all
als
o a
llo
w f
or
the
re
cord
ing
of
the
sig
nif
ica
nt
pa
ram
ete
rs a
nd
act
ion
s.
Hy
po
/Hy
pe
r W
arn
ing
;
Su
gg
est
In
suli
n D
ose
;
RD
MM
-10
6
Da
ta s
tora
ge
F
ev
er
an
d i
nfe
ctio
ns
sha
ll
be
re
gis
tere
d
Fe
ve
r is
ve
ry o
fte
n a
sso
cia
ted
wit
h
insu
lin
re
sist
an
ce w
hic
h m
ea
ns
tha
t th
e p
ati
en
t n
ee
ds
mo
re
insu
lin
.
Fe
ve
r a
nd
in
fect
ion
s sh
all
be
reg
iste
red
in
th
e d
ata
ma
na
ge
me
nt
wh
ere
th
ey
ca
n b
e
retr
ieve
d f
or
com
po
sin
g t
he
feve
r/su
ga
r ch
art
. W
he
n
est
ima
tin
g t
he
in
suli
n r
esi
sta
nce
,
clin
icia
ns
sha
ll h
ave
acc
ess
to
this
in
form
ati
on
.
Vis
ua
lize
in
div
idu
al
pa
tie
nt
glu
cose
an
d
Insu
lin
; V
isu
ali
ze W
ard
Su
mm
ary
RD
MM
-10
5
Da
ta s
tora
ge
R
eg
istr
ati
on
of
spe
cifi
c
inte
rfe
rin
g d
rug
s (i
ncl
ud
ing
the
ir d
osa
ge
)
So
me
dru
gs
inte
rfe
re w
ith
gly
cae
mia
ma
na
ge
me
nt:
sy
ste
mic
inte
rfe
ren
ce (
e.g
. co
rtis
on
e b
y
incr
ea
sin
g b
loo
d g
luco
se),
an
aly
tica
l in
terf
ere
nce
wit
h
glu
cose
mo
nit
ori
ng
de
vic
es
(e.g
.
fru
cto
se,
ma
lto
se-
inte
rfe
ren
ce).
Th
eir
ad
min
istr
ati
on
sh
ou
ld b
e
reg
iste
red
.
Th
e d
ata
ma
na
ge
me
nt
sha
ll
all
ow
fo
r th
e i
nse
rtio
n o
f sp
eci
fic
inte
rfe
rin
g d
rug
s (i
ncl
ud
ing
th
eir
do
sag
e).
Ma
nu
al
Da
ta E
ntr
y
RD
MM
-42
D
ata
sto
rag
e
Se
t o
f a
lert
s a
nd
re
min
de
rs
A s
et
of
po
ssib
le a
lert
s a
nd
rem
ind
ers
. T
he
se c
an
be
th
ou
gh
t
as
"pro
toty
pe
s".
Act
ion
ru
les
can
de
fin
e w
he
n a
nd
ho
w t
he
y m
ust
be
se
nt
wit
h w
hic
h p
ara
me
ters
.
Ale
rts
an
d r
em
ind
ers
ca
n b
e
de
fin
ed
an
d s
tore
d.
Glu
cose
Me
asu
rem
en
t
Re
min
de
r; H
yp
o/H
yp
er
Wa
rnin
g
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
60 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-10
4
Da
ta s
tora
ge
N
utr
itio
n i
nfo
rma
tio
n h
as
to b
e s
tore
d i
n t
he
da
ta
ma
na
ge
me
nt
Co
mp
osi
tio
n (
pro
tein
s, f
at
an
d
carb
oh
yd
rate
s) o
f th
e m
ea
l h
as
to
be
re
cord
ed
an
d u
sed
fo
r th
e
insu
lin
eva
lua
tio
n (
the
use
of
gly
cae
mic
in
de
x a
nd
lo
ad
ta
ble
s
for
vari
ou
s ty
pe
s o
f fo
od
mig
ht
be
tak
en
in
to a
cco
un
t).
Als
o o
the
r
pa
ram
ete
rs h
ave
to
be
ta
ke
n i
nto
acc
ou
nt
(sn
ack
s in
be
twe
en
,
fast
ing
, sp
eci
al
die
t, d
iarr
ho
ea
,
vom
itin
g,
dim
inis
he
d/a
bse
nce
of
ap
pe
tite
). A
lso
sp
eci
al
con
dit
ion
s
rela
ted
to
nu
trit
ion
ha
ve t
o b
e
con
sid
ere
d (
PE
G t
ub
e /
pa
ren
tera
l
fee
din
g,
fast
ad
sorp
tio
n o
f IV
ad
min
iste
red
flu
ids)
.
Th
e d
ata
ma
na
ge
me
nt
sha
ll
all
ow
th
e i
nse
rtio
n o
f ti
me
an
d
com
po
siti
on
of
nu
trit
ion
acc
om
pa
nie
d a
lso
by
ad
dit
ion
al
(co
nte
xt)
pa
ram
ete
rs.
Th
e
do
sag
e o
f in
suli
n s
ha
ll v
ary
wit
h
the
va
ria
tio
n o
f th
e n
utr
itio
n.
Ma
nu
al
Da
ta E
ntr
y
RD
MM
-32
D
ata
str
uct
ure
D
yn
am
ic d
ata
str
uct
ure
fo
r
inp
ati
en
t d
ata
sto
rag
e
Fo
r th
e i
mp
ati
en
t p
ilo
t a
pp
lica
tio
n
(eD
SS
) a
dy
na
mic
da
ta s
tru
ctu
re
for
da
ta s
tora
ge
ha
s to
be
imp
lem
en
ted
. D
ata
fie
lds
sho
uld
be
fle
xib
ly d
efi
ne
d.
A s
uit
ab
le
mo
de
l ca
n b
e t
he
En
tity
-att
rib
ute
-
valu
e (
EA
V)
mo
de
l.
Dy
na
mic
da
ta s
tru
ctu
re f
or
da
ta
sto
rag
e w
ill
be
ava
ila
ble
fo
r
inp
ati
en
t p
ilo
t a
pp
lica
tio
n.
Ad
min
iste
r G
lyca
em
ic
Ma
na
ge
me
nt
RD
MM
-51
D
ata
se
ma
nti
cs
Me
cha
nis
tic
mo
de
l a
nd
rule
s fo
r in
suli
n d
ose
pre
dic
tio
n (
pri
ma
ry c
are
)
A p
hy
sio
log
ic m
od
el
an
d
calc
ula
tio
n r
ule
s/a
lgo
rith
m m
ust
be
sto
red
fo
r in
suli
n d
osi
ng
sup
po
rt.
Ne
cess
ary
mo
de
ls a
nd
ru
les
are
de
fin
ed
an
d s
tore
d.
Su
gg
est
In
suli
n D
ose
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
61 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-96
D
ata
se
ma
nti
cs
Ele
ctro
nic
fe
ver/
sug
ar
cha
rt
Cu
rre
ntl
y m
ed
ica
l h
isto
ry,
ge
ne
ral
he
alt
h s
tatu
s, a
ctu
al
sta
tus,
nu
trit
ion
an
d a
sso
cia
ted
con
dit
ion
s, p
lan
ne
d e
xam
ina
tio
ns
& t
rea
tme
nts
, in
tera
ctio
n w
ith
oth
er
me
dic
ati
on
, b
loo
d g
luco
se
me
asu
rem
en
ts,
do
se t
yp
e a
nd
tim
ing
of
insu
lin
or
OA
D a
re s
tore
d
in a
pa
pe
r-b
ase
d f
eve
r/su
ga
r
cha
rt.
Th
e s
am
e i
nfo
rma
tio
n
sho
uld
be
ava
ila
ble
in
an
ele
ctro
nic
fe
ver/
sug
ar
cha
rt w
hic
h
can
be
acc
ess
ed
an
d s
ha
red
by
seve
ral
use
rs a
t th
e s
am
e t
ime
.
In t
he
de
sig
n o
f th
e d
ata
ma
na
ge
me
nt
the
ele
ctro
nic
feve
r/su
ga
r ch
art
(o
r th
e
po
ssib
ilit
y t
o c
om
po
se i
t fr
om
the
sto
red
da
ta)
ha
s to
be
pre
sen
t. I
ts a
cce
ss m
ust
be
mu
lti-
use
r. T
he
fe
ve
r/su
ga
r ch
art
ha
s to
be
in
itia
lize
d a
t th
e
pa
tie
nt
en
rolm
en
t a
nd
up
da
ted
at
an
y d
ata
acq
uis
itio
n.
Init
ial
pa
tie
nt
he
alt
h
sta
tus
da
ta e
ntr
y;
Vis
ua
lize
in
div
idu
al
pa
tie
nt
glu
cose
an
d
insu
lin
RD
MM
-43
D
ata
se
ma
nti
cs
Mo
de
ls a
nd
ru
les
for
insu
lin
do
se p
red
icti
on
(in
pa
tie
nt)
A p
hy
sio
log
ic m
od
el
an
d
calc
ula
tio
n r
ule
s/a
lgo
rith
m m
ust
be
sto
red
fo
r in
suli
n d
osi
ng
sup
po
rt b
ase
d o
n c
lin
ica
l
pro
toco
ls.
Ne
cess
ary
mo
de
ls a
nd
ru
les
are
de
fin
ed
an
d s
tore
d.
Su
gg
est
In
suli
n D
ose
RD
MM
-12
4
Da
ta s
em
an
tics
V
isu
ali
zati
on
of
curr
en
t
"in
suli
n o
n b
oa
rd"
an
d
"ca
rbo
hy
dra
tes
on
bo
ard
"
As
pa
rt o
f e
lect
ron
ic d
eci
sio
n
sup
po
rt t
he
cu
rre
nt
"in
suli
n o
n
bo
ard
" a
nd
"ca
rbo
hy
dra
tes
on
bo
ard
" sh
ou
ld b
e p
rese
nte
d t
o t
he
ph
ysi
cia
ns
an
d n
urs
es.
Me
tho
ds/
Fu
nct
ion
s:
- tr
en
d i
nfo
rma
tio
n
- a
ctiv
e p
rofi
le o
f in
suli
n o
n b
oa
rd
(usi
ng
ph
ysi
olo
gic
al
mo
de
ls)
Inp
ati
en
t p
roto
typ
e p
rovi
de
s
visu
ali
zati
on
of
curr
en
t "i
nsu
lin
on
bo
ard
" a
nd
"ca
rbo
hyd
rate
s
on
bo
ard
" fo
r d
eci
sio
n s
up
po
rt.
Vis
ua
lize
in
div
idu
al
pa
tie
nt
glu
cose
an
d
insu
lin
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
62 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-64
D
ata
se
ma
nti
c C
on
text
ma
na
ge
me
nt
for
clin
ica
l (l
ab
) va
lue
s.
Co
nte
xtu
ali
zati
on
of
me
asu
red
valu
es
(e.g
. b
loo
d g
luco
se v
alu
es)
is i
mp
ort
an
t in
ord
er
to s
up
po
rt
RE
AC
TIO
N a
pp
lica
tio
ns
lik
e
de
cisi
on
su
pp
ort
. F
or
exa
mp
le p
re-
or
po
st-m
ea
l g
luco
se v
alu
es
ha
ve
very
dif
fere
nt
me
an
ing
s fo
r
tre
atm
en
t. T
he
refo
re t
he
da
ta
ma
na
ge
me
nt
mo
de
l h
as
to
pro
vid
e c
on
text
ma
na
ge
me
nt.
Th
e d
ata
ma
na
ge
me
nt
mo
de
l
sup
po
rt c
on
text
ma
na
ge
me
nt
fun
ctio
na
lity
fo
r th
e i
np
ati
en
t
pro
toty
pe
ap
pli
cati
on
.
Ad
min
iste
r G
lyca
em
ic
Ma
na
ge
me
nt
6.1.4 Implications for REACTION Platform Technology
The following implications for the REACTION data management model/architecture can be derived from the gathered data model requirements:
Data Interface
The inpatient prototype requires various interfaces to internal and external systems. In order to enable the system to identify and manage patients on the ward, an interface to the patient demographic register of the hospital information system will be necessary. The Interface will be based on HL7. Moreover, lab data, especially glucose values, need to be transferred into the prototype system. An interface to the Lab Information System (LIS) is required for this task. If possible HL7 will be the preferred communication standard. If glucose values cannot be transferred from the Point-if-Care Testing (POCT) device via LIS to the prototype in time, an interface for the direct transmission of glucose values from POCT system to inpatient prototype has be provided.
Clinical data will be imported using an interface to the Hospital Information System. Again HL7 should be the preferred standard. Various values will be entered via the user-interface of the mobile device hosting the eDSS. Therefore an interface for user inputs has to be provided. Moreover, (Web) Service to present decision support for glucose control to clinicians has to be implemented.
In the first development phase, the inpatient prototype will be embedded into the technical environment of the hospital information system. In order to enable communication between inpatient prototypes, REACTION platform services and interfaces have to be provided.
Data Source
Different data will be required in order to perform decision support for insulin dosing in the general ward. Besides administrative data such as sex, age, or assigned hospital bed, clinical information such as type of diabetes, co-morbidities, drugs and symptoms such as fever, infection, diarrhea, vomiting or hypo- hyperglycemia are required. Moreover, laboratory data like HbA1c, glucose values, nutrition and also context data (e.g. time of glucose measurement, device type) will be needed. A detailed enumeration of required data can be found in the elicited requirements.
Data Storage
Data has to be stored within the inpatient environment in an adequate manner. Thus, the inpatient prototype should allow usual database operations like insertion, update or retrieval of data.
Data Structure
In order to hold the data for the impatient pilot application, a dynamic data structure for data storage has to be implemented. Data fields should be flexibly defined. A suitable model could be the Entity-attribute-value (EAV) model (Dinu2007).
Data Semantics
The complex management of data, information and knowledge is an important feature of the inpatient prototype. The data management model has to consider data semantics in order to gain information and knowledge from source data for following applications:
• Mechanistic model and rules for insulin dose prediction
• Adaptable electronic fever/sugar chart that meet requirements of physicians
• Visualization of current "insulin on board" and "carbohydrates on board"
• Context management for clinical (lab) values
Data Security
In the first development phase, the inpatient prototype will be fully embedded into the technical environment of the University Hospital of Graz. The hospital information system implements various mechanisms to ensure security and privacy of personal patient data. If the inpatient prototype is coupled with the REACTION platform, security mechanisms as summarised in Section 5.6.2 will be performed.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 64 of 85 DATE 2010-08-31
6.2 Primary Care Diabetes Management
6.2.1 Introduction
There are several measures and interventions known to improve the quality of diabetes care in general practice and specialised units outside the hospital. Many of them have previously been sufficiently evaluated and found beneficial – most of them have a higher impact on metabolic control than pharmaceutical agents in non-inferiority trials. There is therefore a solid basis of evidence for their recommendation, further implementation in the healthcare system and further research.
These measures and interventions are not purely medical but can also cover many organisational aspects which interact with the way healthcare generally is organised in a region. The following measures and interventions, which can often be facilitated or supported by information technology, have been taken into account
5.
Patient education
Patient education and self management are well established elements in the therapy of chronic diseases, as recommended by evidence-based guidelines. Self management education is not only about knowledge transfer, but more about developing and training problem-solving skills, so that the patient can participate and play an active role in the management of the chronic disease.
Telemonitoring - Self management support
Provision of equipment and resources for example for measuring blood glucose at home, electronically transmitting measurements and receiving feedback on insulin dose changes or other adaptations are considered to be measures to promote self-management.
Professional decision support / reminders
Several ways to support healthcare professionals by decision support can be identified. They mainly have the aim of supporting physicians in following clinical guidelines and clinical pathways.
• Repeat important procedures on a regular basis (for example check for risk factors such as eye and foot examination at least once in a year)
• Estimate risk for developing diabetes complications and take appropriate preventive action
• Visualization and intelligent annotation of blood glucose profile as a basis for decision-making
• Workflow (referrals – cooperation with other disciplines, treatment intervals)
• Prescription of medication or start of other medical interventions such as education
• Patient recall (actively contact patients to perform an action such as an examination or education)
Reminders can either be presented as computerised prompts, generated at the point of care for the professional. Alternatively another form of reminders is to analyse the data in the disease register/patient record to generate lists of patients for which a specific action should be taken (invite to practice = recall, send information leaflet etc.). Computerised prompts have the potential to cover several aspects at once and are therefore of special interest for quality improvement.
Patient decision support / reminders
These are all efforts to remind patients about upcoming appointments or important aspects of self-care. The content of these reminders is usually computer generated. Communication can either be performed via traditional channels like postcards or telephone calls or electronically.
Structured, electronic documentation
Electronic records or disease registers are commonly used and form the basis for structured documentation which can be taken a step further for use in measures like decision support and quality reporting.
5 A closer examination of the scientific evidence will be taken in D6.1 “Assessment of existing disease management strategies
including available risk assessment tools and their parameters”.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 65 of 85 DATE 2010-08-31
However, interoperability between systems, especially between different sectors and layers of the healthcare system, is still not sufficiently developed and requires some practical solutions.
Quality Reporting - Audit and Feedback
Feedback about quality of care is a summary of clinical performance of health care which was delivered by an individual clinician or a surgery/clinic over a specified period. Examples of feedback presented to the clinicians include the percentage of a clinician’s patients who have achieved a target HbA1c level, or who have undergone a foot examination with a specified frequency etc.
Interdisciplinary care teams
In several studies, especially in the fields of diabetes and hypertension, changes to the structure or organization of the primary health care team have proven to be the most effective. This team change can take the form of either the revision of professional roles (e.g. nurse or pharmacist plays a more active role in patient monitoring or adjusting medication regimens), the use of multidisciplinary teams (e.g. cooperation of medicine, nursing, pharmacy, nutrition in the primary, ongoing management of patients) or adding a team member via “shared care” (e.g. routine visits with personnel other than the primary physician).
Of course these changes mainly require a paradigm shift and cannot be directly introduced via technology. But for the requirements analysis, we have to be aware of the fact that the developed technology has to support various ways of cooperation between healthcare professionals in different roles and different levels of institutional integration.
Interactive health communication applications
Interactive health communication applications are computer-based, usually web-based, applications for patients that combine health information with at least one type of support (social, decision or behaviour change support).
These applications have the potential to improve knowledge by providing information to patients. Furthermore these applications provide support to patients in several ways (social support, behaviour change support, decision support). The supportive inputs together with the provided information and patient’s knowledge can combine to lead to improved motivation and self-efficacy (patient’s belief in the own ability to carry out a specific action) and affective changes (e.g. reduced anxiety). These changes lead to a behaviour change which can result in improved clinical outcomes and quality of life.
6.2.2 Use-Case Diagram for Primary Care Diabetes Management
Diabetes mellitus is a chronic disease which starts slowly and progresses continuously. For this reason diabetes is diagnosed and treated mainly by primary care. In several healthcare systems in Europe, specialised units for diabetes care exist although their form and integration in health care varies (either hospital clinics mainly caring for complications as is the case in the U.K. or specialist practices outside the hospital that also take part in routine diabetes care as in Germany). REACTION aims at building a platform to support routine care for diabetes patients. Several aspects have been identified, which the REACTION platform aims to support:
� Continuous professional care: this comprises measures and actions to support disease management and patient care in the physician surgery.
� Self-management: this comprises measures and actions to support the patient in taking an active role in the management of the disease, supported by devices and an infrastructure to communicate measured values and receive support.
� Practice Organisation: Steps to improve quality of care to be taken at the level of the organisation (e.g. clinic, surgery).
� Administration: Required administrative steps The Use-Cases envisioned for the REACTION project are given in Figure 5.
.
Fig
ure
5:
Use-C
ase D
iagra
m f
or
Prim
ary
Care
Dia
bete
s M
anagem
ent
6.2.3 List of Requirements
Ke
y
Re
qu
ire
me
nt
sub
typ
e
Su
mm
ary
R
ati
on
ale
F
it C
rite
rio
n
Lin
k t
o U
se-C
ase
RD
MM
-80
D
ata
so
urc
e
Pa
tie
nt
ed
uca
tio
n
Co
nti
nu
ou
s e
du
cati
on
of
the
pa
tie
nt
ad
just
ed
to
his
/he
r n
ee
ds.
Ed
uca
tio
na
l m
ate
ria
l is
ava
ila
ble
. P
ati
en
t S
elf
-
ma
na
ge
me
nt
sup
po
rt
RD
MM
-92
D
ata
so
urc
e
Inse
rtio
n o
f b
ase
lin
e
ph
ysi
olo
gic
al
me
asu
rem
en
ts a
t th
e f
irst
visi
t
At
the
fir
st v
isit
ba
seli
ne
ph
ysi
olo
gic
al
me
asu
rem
en
ts (
Th
e
exa
ct s
et
ha
s to
be
cle
arl
y d
efi
ne
d)
ha
ve t
o b
e i
nse
rte
d i
n t
he
pla
tfo
rm.
Th
e d
ata
ma
na
ge
me
nt
sha
ll
fore
see
th
e p
oss
ibil
ity
of
intr
od
uci
ng
th
e b
ase
lin
e
ph
ysi
olo
gic
al
me
asu
rem
en
ts a
t
the
fir
st v
isit
(ju
st a
fte
r th
e
pa
tie
nt
en
rolm
en
t).
Str
uct
ure
d
do
cum
en
tati
on
RD
MM
-58
D
ata
sto
rag
e
Dif
fere
nt
sta
ge
s fo
r th
e
pa
tie
nt
ma
na
ge
me
nt
in
ou
tpa
tie
nt
en
viro
nm
en
t
Dif
fere
nt
act
ion
s h
ave
to
be
pe
rfo
rme
d i
n d
iffe
ren
t st
ag
es
(ne
wly
dia
gn
ose
d /
me
dic
ati
on
titr
ati
on
/ i
nve
stig
ati
ve
sta
ge
,
on
go
ing
ma
na
ge
me
nt)
fo
r th
e
pa
tie
nt
ma
na
ge
me
nt
in o
utp
ati
en
t
en
viro
nm
en
t.
Th
e d
ata
ma
na
ge
me
nt
ha
s to
all
ow
th
e s
tora
ge
of
the
sta
ge
of
ma
na
ge
me
nt
for
ea
ch p
ati
en
t.
RD
MM
-60
D
ata
sto
rag
e
Inve
stig
ati
ve
sta
ge
A
n i
nve
stig
ati
ve
sta
ge
ha
s to
be
use
d i
n a
ll n
ew
ly d
iag
no
sed
dia
be
tic
pa
tie
nts
. T
his
sta
ge
(wh
ich
du
rati
on
ha
s to
be
se
t-u
p
by
cli
nic
ian
s) h
as
to b
e u
sed
fo
r:
con
firm
dia
gn
osi
s, c
he
ck
eff
ect
ive
ne
ss o
f li
fest
yle
an
d
me
dic
ati
on
s, e
valu
ate
th
e o
pti
ma
l
do
sag
e o
f m
ed
ica
tio
ns,
pe
rfo
rm
pa
tie
nt
ed
uca
tio
n o
n d
iab
ete
s,
rea
ssu
re p
ati
en
ts c
on
cern
ed
ab
ou
t
the
ir b
loo
d s
ug
ar
lev
els
.
Sp
eci
fic
fie
lds
ha
ve
to
be
pre
sen
t
in o
nto
log
ies
an
d d
ata
ma
na
ge
me
nt.
Co
nti
nu
ou
s
Pro
fess
ion
al
care
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
68 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-61
D
ata
sto
rag
e
On
go
ing
ma
na
ge
me
nt
Aft
er
the
in
ve
stig
ati
ve
sta
ge
th
ere
ha
s to
be
th
e o
ng
oin
g
ma
na
ge
me
nt.
Th
is s
tag
e h
as
to b
e
use
d f
or:
su
pp
ort
pa
tie
nts
wit
h
dif
ficu
ltie
s in
ma
na
gin
g t
he
ir
dia
be
tes,
ch
eck
eff
ect
ive
ne
ss o
f
life
sty
le a
nd
me
dic
ati
on
s, e
valu
ate
the
op
tim
al
do
sag
e o
f
me
dic
ati
on
s, p
erf
orm
pa
tie
nt
ed
uca
tio
n o
n d
iab
ete
s, s
up
po
rt
cha
ng
es
in p
ati
en
t li
fest
yle
,
ide
nti
fy b
ett
er
dia
be
tes
ma
na
ge
me
nt
for
pa
tie
nts
.
Sp
eci
fic
fie
lds
ha
ve
to
be
pre
sen
t
in o
nto
log
ies
an
d d
ata
ma
na
ge
me
nt
Co
nti
nu
ou
s
pro
fess
ion
al
care
/
Str
uct
ure
d
Do
cum
en
tati
on
/
De
cisi
on
su
pp
ort
RD
MM
-69
D
ata
sto
rag
e
Re
aso
ns
for
en
d o
f p
roce
ss
in o
utp
ati
en
t e
nvi
ron
me
nt
Th
ere
is
no
en
d o
f p
roce
ss i
n
pri
ma
ry c
are
; th
e p
ati
en
t w
ill
on
ly
lea
ve
pri
ma
ry c
are
if
he
die
s o
r
lea
ve
s th
e p
ract
ice
du
e t
o m
ovi
ng
aw
ay
fro
m t
he
pra
ctic
e c
atc
hm
en
t
are
a o
r vo
lun
tari
ly s
top
s to
be
mo
nit
ore
d b
y t
he
RE
AC
TIO
N
pla
tfo
rm.
Pa
tie
nt
dis
cha
rge
fro
m t
he
ou
tpa
tie
nt
en
viro
nm
en
t sh
all
ha
ve t
he
fo
llo
win
g o
pti
on
s: a
)
de
ath
; b
) p
ati
en
t re
mo
val
ou
tsid
e f
rom
th
e p
ract
ice
catc
hm
en
t a
rea
; c)
pa
tie
nt
volu
nta
rily
sto
ps
to b
e
mo
nit
ore
d b
y t
he
RE
AC
TIO
N
pla
tfo
rm.
Str
uct
ure
d
do
cum
en
tati
on
RD
MM
-71
D
ata
sto
rag
e
Ca
re s
pa
ce i
n o
utp
ati
en
t
en
viro
nm
en
t
Pa
tie
nts
an
d i
nfo
rma
l ca
rers
ha
ve
to b
e i
ncl
ud
ed
in
th
e p
roce
ss o
f
care
. C
are
sp
ace
s (f
or
ea
ch
pa
tie
nt)
ha
ve t
o b
e d
ev
elo
pe
d
wh
ere
th
e r
ole
s a
nd
ta
sks
are
dis
trib
ute
d a
mo
ng
th
e
mu
ltid
isci
pli
na
ry h
ea
lth
ca
re t
ea
m
me
mb
ers
.
Th
e d
ata
ma
na
ge
me
nt
sha
ll
all
ow
th
e s
tora
ge
of
the
ca
re
spa
ce f
or
ea
ch p
ati
en
t w
ith
spe
cifi
c ro
les
for
ea
ch m
em
be
r
of
the
ca
re s
pa
ce.
Str
uct
ure
d
do
cum
en
tati
on
/
Ma
inta
in
(te
lem
on
ito
rin
g)
pro
file
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
69 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-93
D
ata
sto
rag
e
Cli
nic
al
case
co
nfe
ren
ce
An
y p
oss
ible
cri
tica
l si
tua
tio
n h
as
to b
e a
ccu
rate
ly v
eri
fie
d b
y t
he
care
cli
nic
al
tea
m w
ith
th
e s
up
po
rt
of
virt
ua
l vi
sits
th
rou
gh
e.g
. th
e
use
of
vid
eo
-co
nfe
ren
ce.
Th
e
com
ple
tio
n o
f th
e a
ccu
rate
ch
eck
sha
ll b
e a
cco
mp
an
ied
by
ch
an
ge
s
in t
he
pa
tie
nt
tre
atm
en
t (i
f
ne
cess
ary
) a
nd
als
o c
ha
ng
es
in t
he
RP
M s
che
ma
ha
ve
to
be
all
ow
ed
.
A c
lin
ica
l ca
se c
on
fere
nce
re
po
rt
ha
s to
be
sto
red
.
Sto
rag
e a
nd
re
trie
val
of
clin
ica
l
case
co
nfe
ren
ce r
ep
ort
s h
as
to
be
po
ssib
le.
RD
MM
-57
D
ata
str
uct
ure
6
-mo
nth
cli
nic
al
che
cks
Eve
ry 6
mo
nth
s th
e f
oll
ow
ing
te
sts
ha
ve t
o b
e p
erf
orm
ed
: b
loo
d t
est
s
as
in t
he
an
nu
al
clin
ica
l ch
eck
s
(exc
ep
t fo
r th
e t
hy
roid
fu
nct
ion
test
s),
BM
I, b
loo
d p
ress
ure
me
asu
rem
en
ts,
che
ck s
mo
kin
g
sta
tus,
re
vie
w o
f m
ed
ica
tio
ns
(in
clu
din
g d
iet
an
d l
ife
sty
le
me
asu
res)
.
Sp
eci
fic
fie
lds
(en
trie
s) h
av
e t
o
be
fo
rese
en
in
on
tolo
gie
s a
nd
da
ta m
an
ag
em
en
t.
Co
nti
nu
ou
s
pro
fess
ion
al
Ca
re /
Str
uct
ure
d
do
cum
en
tati
on
/
qu
ali
ty m
an
ag
em
en
t
RD
MM
-56
D
ata
str
uct
ure
A
nn
ua
l cl
inic
al
che
cks
Th
e a
nn
ua
l cl
inic
al
che
cks
for
the
ou
tpa
tie
nt
en
viro
nm
en
t in
clu
de
s
(wit
h t
he
ne
cess
ary
att
rib
ute
s):
foo
t ch
eck
, re
tin
al
scre
en
ing
(ph
oto
gra
ph
of
pa
tie
nt'
s re
tin
ae
),
test
fo
r p
rote
in,
he
igh
t a
nd
we
igh
t, B
MI,
blo
od
pre
ssu
re
me
asu
rem
en
t, c
he
ck s
mo
kin
g
sta
tus,
blo
od
te
st (
glu
cose
le
ve
l,
Hb
A1
c, e
tc.)
, ch
eck
/ad
min
iste
r fl
u
inje
ctio
ns,
de
pre
ssio
n s
cre
en
ing
,
revi
ew
of
me
dic
ati
on
(in
clu
din
g
die
t a
nd
lif
est
yle
me
asu
res)
.
Sp
eci
fic
fie
lds
ha
ve
to
be
pre
sen
t
in o
nto
log
ies
an
d d
ata
ma
na
ge
me
nt.
Co
nti
nu
ou
s
pro
fess
ion
al
Ca
re /
Str
uct
ure
d
do
cum
en
tati
on
/
com
pli
cati
on
an
d r
isk
est
ima
tio
n /
qu
ali
ty
ma
na
ge
me
nt
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
70 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-67
D
ata
str
uct
ure
M
an
ag
em
en
t o
f
com
pli
cati
on
s
Ap
art
fro
m t
he
dia
be
tic
ma
na
ge
me
nt,
th
e o
the
r
ma
na
ge
me
nts
fo
r d
iab
eti
c
pa
tie
nts
wil
l b
e a
rou
nd
th
e
com
pli
cati
on
s (c
ard
iova
scu
lar,
ren
al,
op
hth
alm
olo
gy
,
ma
na
ge
me
nt
of
foo
t a
nd
ne
uro
pa
thy
pro
ble
ms)
.
Da
ta m
an
ag
em
en
t sh
ou
ld
incl
ud
e t
he
ne
cess
ary
str
uct
ure
s
for
ass
uri
ng
th
e s
tora
ge
of
all
ne
cess
ary
in
form
ati
on
fo
r th
e
ma
na
ge
me
nt
of
com
pli
cati
on
s.
Str
uct
ure
d
Do
cum
en
tati
on
/
Co
nti
nu
ou
s
pro
fess
ion
al
care
/
Exc
ha
ng
e
do
cum
en
tati
on
(acr
oss
la
ye
rs)
/
De
cisi
on
su
pp
ort
RD
MM
-42
D
ata
str
uct
ure
S
et
of
ale
rts
an
d r
em
ind
ers
A
se
t o
f p
oss
ible
ale
rts
an
d
rem
ind
ers
. T
he
se c
an
be
th
ou
gh
t
as
"pro
toty
pe
s".
Act
ion
ru
les
can
de
fin
e w
he
n a
nd
ho
w t
he
y m
ust
be
se
nt
wit
h w
hic
h p
ara
me
ters
.
Ale
rts
an
d r
em
ind
ers
ca
n b
e
de
fin
ed
an
d s
tore
d.
De
cisi
on
Su
pp
ort
Pro
mp
ts f
or
GP
or
nu
rse
RD
MM
-68
D
ata
str
uct
ure
O
utc
om
es
of
reg
ula
r vi
sits
at
pri
ma
ry h
ea
lth
ca
re
cen
tre
s
Ou
tco
me
s o
f re
gu
lar
visi
ts a
t th
e
pri
ma
ry h
ea
lth
ca
re c
en
ter
sha
ll b
e
reg
iste
red
th
rou
gh
th
e d
ata
ma
na
ge
me
nt.
Th
e o
utc
om
es
of
ea
ch v
isit
ha
ve
to b
e s
tore
d a
s m
uch
as
po
ssib
le
in a
str
uct
ure
d w
ay
.
Str
uct
ure
d
do
cum
en
tati
on
RD
MM
-13
1
Da
ta s
tru
ctu
re
Co
nsi
de
r p
ati
en
t's
pre
fere
nce
s, w
ish
es
an
d
de
cisi
on
s
Th
e d
ata
se
t sh
ou
ld a
llo
w
do
cum
en
tati
on
of
pa
tie
nt'
s
pre
fere
nce
s, w
ish
es
an
d d
eci
sio
ns.
Th
is i
nfo
rma
tio
n s
ho
uld
als
o b
e
con
sid
ere
d i
n t
he
eva
lua
tio
n o
f
rule
s e
tc.,
so
th
at
no
reco
mm
en
da
tio
ns
ag
ain
st t
he
wil
l
of
the
pa
tie
nt
are
ma
de
.
Pa
tie
nt'
s p
refe
ren
ces,
wis
he
s
an
d d
eci
sio
ns
can
be
do
cum
en
ted
an
d r
ule
s co
nsi
de
r
this
da
ta.
Str
uct
ure
d
Do
cum
en
tati
on
/
De
cisi
on
Su
pp
ort
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
71 o
f 85
DA
TE
2010-0
8-3
1
RD
MM
-45
RD
MM
-46
Da
ta s
tru
ctu
re
an
d d
ata
sem
an
tics
He
alt
h S
tatu
s M
od
el
/
Pe
rso
na
l H
ea
lth
Sta
tus
Pro
file
s
Th
e h
ea
lth
sta
tus
mo
de
l se
rve
s a
s
a g
en
eri
c p
roto
typ
e f
or
Pe
rso
na
l
He
alt
h S
tatu
s P
rofi
les,
i.e
. d
efi
ne
s
its
da
ta c
on
ten
t. T
his
he
lps
to
de
fin
e p
ers
on
al
mo
de
ls (
pro
file
s),
wh
ich
pe
rmit
th
e p
ers
on
ali
sed
dis
ea
se m
an
ag
em
en
t.
Pe
rso
na
l H
ea
lth
Sta
tus
Pro
file
fo
r
ea
ch p
ati
en
t m
ust
be
ge
ne
rate
d,
sto
red
an
d r
eg
ula
rly
up
da
ted
. It
serv
es
as
an
in
pu
t fo
r ri
sk
ass
ess
me
nt
an
d d
ise
ase
ma
na
ge
me
nt.
Pe
rso
na
l H
ea
lth
Sta
tus
Pro
file
s
can
be
ge
ne
rate
d.
Str
uct
ure
d
do
cum
en
tati
on
/
De
cisi
on
su
pp
ort
/
Ris
k e
stim
ati
on
RD
MM
-38
D
ata
se
ma
nti
cs
Mo
nit
ori
ng
sch
em
e
Ind
ivid
ua
l m
on
ito
rin
g s
che
me
fo
r
ea
ch p
ati
en
t m
ust
be
de
fin
ed
an
d
sto
red
. T
his
de
scri
be
s w
ha
t
pa
ram
ete
rs a
nd
ho
w o
fte
n s
ho
uld
be
me
asu
red
.
An
in
div
idu
al
mo
nit
ori
ng
sch
em
e
can
be
de
fin
ed
fo
r e
ach
pa
tie
nt.
Ma
inta
in
tele
mo
nit
ori
ng
pro
file
/ S
elf
-ma
na
ge
me
nt
Ty
pe
1 a
nd
2
RD
MM
-43
D
ata
se
ma
nti
cs
Mo
de
ls a
nd
ru
les
for
insu
lin
do
se p
red
icti
on
(in
pa
tie
nt)
A p
hy
sio
log
ic m
od
el
an
d
calc
ula
tio
n r
ule
s/a
lgo
rith
m m
ust
be
sto
red
fo
r in
suli
n d
osi
ng
sup
po
rt b
ase
d o
n c
lin
ica
l
pro
toco
ls.
Ne
cess
ary
mo
de
ls a
nd
ru
les
are
de
fin
ed
an
d s
tore
d.
RD
MM
-44
D
ata
se
ma
nti
cs
Ris
k a
sse
ssm
en
t m
od
els
an
d r
ule
s
Mo
de
ls a
nd
ru
les
mu
st b
e d
efi
ne
d
to d
ete
rmin
e p
ers
on
al
risk
s.
Mo
de
ls a
nd
ru
les
for
risk
ass
ess
me
nt
are
pre
sen
t.
Dia
be
tes
com
pli
cati
on
Ris
k e
stim
ati
on
RD
MM
-51
D
ata
sem
an
tics
Me
cha
nis
tic
mo
de
l a
nd
rule
s fo
r in
suli
n d
ose
pre
dic
tio
n (
pri
ma
ry c
are
)
A p
hy
sio
log
ic m
od
el
an
d
calc
ula
tio
n r
ule
s/a
lgo
rith
m m
ust
be
sto
red
fo
r in
suli
n d
osi
ng
sup
po
rt.
Ne
cess
ary
mo
de
ls a
nd
ru
les
are
de
fin
ed
an
d s
tore
d.
Insu
lin
do
sin
g a
dvi
ce
RD
MM
-13
2
Da
ta s
em
an
tics
Ma
na
ge
me
nt
of
refe
rra
ls t
o
an
d r
esp
on
ses
fro
m o
the
r
ph
ysi
cia
ns
(via
EH
R
inte
rfa
ce)
Re
ferr
als
are
pa
rt o
f cl
inic
al
pa
thw
ay
s a
nd
tre
atm
en
t p
lan
.
Re
ferr
als
sh
ou
ld b
e d
ocu
me
nte
d
an
d t
he
re
com
me
nd
ati
on
of
refe
rra
ls s
ho
uld
be
co
nsi
de
red
in
de
cisi
on
su
pp
ort
ru
les.
..
Re
ferr
als
ca
n b
e d
ocu
me
nte
d
an
d a
re c
on
sid
ere
d i
n d
eci
sio
n
sup
po
rt,
sum
ma
ry l
ett
ers
ca
n b
e
rece
ive
d v
ia a
n a
pp
rop
ria
te d
ata
inte
rfa
ce.
Str
uct
ure
d
do
cum
en
tati
on
/
Exc
ha
ng
e d
ocu
me
nts
acr
oss
la
ye
rs /
De
cisi
on
Su
pp
ort
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
72 o
f 85
DA
TE
2010-0
8-3
1
Su
mm
ary
le
tte
rs a
nd
oth
er
"re
spo
nse
s" f
rom
oth
er
he
alt
hca
re
pro
fess
ion
als
sh
ou
ld b
e m
an
ag
ed
.
- O
pti
ma
l so
luti
on
wo
uld
be
an
inte
rfa
ce t
o a
re
gio
na
l o
r n
ati
on
al
EH
R i
nfr
ast
ruct
ure
(e
.g.
IHE
-XD
S)
fro
m w
he
re d
ocu
me
nts
ca
n b
e
rece
ive
d.
RD
MM
-13
3
Da
ta s
em
an
tics
T
ele
mo
nit
ori
ng
da
ta s
ho
uld
be
vis
ua
lize
d t
o p
ati
en
ts
an
d p
rofe
ssio
na
ls i
n a
fle
xib
le a
nd
pe
rfo
rma
nt
wa
y
GP
s a
nd
nu
rse
s a
s w
ell
as
pa
tie
nts
an
d t
he
ir c
are
rs u
se t
he
tele
mo
nit
ori
ng
da
ta t
o g
et
an
imp
ress
ion
of
the
pa
tie
nt
sta
tus.
So
te
lem
on
ito
rin
g d
ata
ne
ed
s to
be
vis
ua
lize
d i
n a
fle
xib
le w
ay
(ag
gre
ga
tio
n l
ev
el,
co
mb
ina
tio
n o
f
pa
ram
ete
rs .
..)
Da
ta h
as
to b
e h
an
dle
d i
n a
wa
y
tha
t th
is v
isu
ali
zati
on
ca
n b
e
ge
ne
rate
d o
n-d
em
an
d w
ith
go
od
pe
rfo
rma
nce
.
Da
ta c
an
be
vis
ua
lize
d f
lexi
bly
an
d w
ith
go
od
pe
rfo
rma
nce
to
pro
fess
ion
als
Vis
ua
lize
Blo
od
Glu
cose
(P
rofe
ssio
na
l
Vie
w /
Pa
tie
nt
Vie
w)
RD
MM
-49
O
the
r P
ers
on
ali
zed
ca
re p
lan
A
pe
rso
na
lize
d c
are
pla
n m
ust
be
de
fin
ed
(a
nd
up
da
ted
if
ne
cess
ary
)
for
ea
ch p
ati
en
t. I
t in
clu
de
s
dis
ea
se m
an
ag
em
en
t, r
isk
ma
na
ge
me
nt
an
d l
ife
sty
le p
lan
.
Pe
rso
na
liza
tio
n m
eth
od
s m
ust
be
de
fin
ed
.
Ca
re p
lan
ca
n b
e p
ers
on
ali
zed
. S
tru
ctu
red
do
cum
en
tati
on
/ R
isk
ma
na
ge
me
nt
/
Te
lem
on
ito
rin
g P
rofi
le
RD
MM
-81
O
the
r S
elf
-ma
na
ge
me
nt
an
d
life
sty
le s
up
po
rt
Su
pp
ort
of
the
pa
tie
nts
' se
lf-
ma
na
ge
me
nt
by
lif
est
yle
(d
iet,
exe
rcis
e e
tc.)
ad
vic
es,
th
era
py
ad
vice
s, h
ea
lth
sta
tus
ass
ess
me
nt.
Se
lf-m
an
ag
em
en
t is
su
pp
ort
ed
. S
elf
-ma
na
ge
me
nt
Ty
pe
2 d
iab
ete
s /
Pa
tie
nt
fee
db
ack
Ty
pe
1 d
iab
ete
s
RD
MM
-12
9
Oth
er
Sca
lab
le /
ea
sy t
o u
se
solu
tio
n f
or
RE
AC
TIO
N
soft
wa
re i
n G
P s
urg
ery
Th
e R
EA
CT
ION
so
ftw
are
wh
ich
is
exe
cute
d i
n t
he
GP
su
rge
ry h
as
to
be
usa
ble
fo
r p
ract
ice
s in
dif
fere
nt
sett
ing
wit
h d
iffe
ren
t E
PR
sy
ste
ms.
It s
ho
uld
pro
vid
e a
use
r in
terf
ace
for
dis
ea
se m
an
ag
em
en
t a
s w
ell
as
RE
AC
TIO
N s
oft
wa
re i
s e
asy
to
run
be
sid
e a
n E
HR
ap
pli
cati
on
or
EH
R m
an
ufa
ctu
rer
is s
ati
sfie
d
wit
h e
ase
of
inte
gra
tio
n o
f
RE
AC
TIO
N
Co
nti
nu
ou
s
pro
fess
ion
al
care
D4-3
Technic
al R
equirem
ents
for
Medic
al D
ata
Managem
ent
RE
AC
TIO
N (
FP
7 2
48590)
VE
RS
ION
1.2
73 o
f 85
DA
TE
2010-0
8-3
1
We
b S
erv
ice
s w
hic
h c
an
be
imp
lem
en
ted
by
EP
R
ma
nu
fact
ure
rs t
o e
asi
ly i
nte
gra
te
RE
AC
TIO
N f
ea
ture
s in
to t
he
ir
pro
du
cts.
RD
MM
-13
0
Oth
er
A R
EA
CT
ION
ap
pli
cati
on
ne
ed
s to
be
exe
cute
d i
n t
he
pa
tie
nt
surg
ery
ind
ep
en
de
nt
fro
m t
he
EP
R
As
it i
s n
ot
po
ssib
le t
o i
nfl
ue
nce
/
mo
dif
y m
an
y E
PR
sy
ste
ms,
RE
AC
TIO
N f
ea
ture
s in
sid
e t
he
GP
surg
ery
ha
ve
to
be
pro
vid
ed
by
a
de
dic
ate
d a
nd
in
de
pe
nd
en
t
ap
pli
cati
on
.
Th
is a
pp
lica
tio
n c
om
mu
nic
ate
s
wit
h
- th
e R
EA
CT
ION
pla
tfo
rm o
ver
the
Inte
rne
t.
- o
the
r sy
ste
ms
in t
he
su
rge
ry
(EP
R,
lab
, e
tc.)
Th
is a
pp
lica
tio
n c
an
be
se
rve
r-
ba
sed
an
d a
lwa
ys
on
, fo
r a
pro
toty
pe
als
o a
n a
pp
lica
tio
n
clie
nt
cou
ld b
e u
sed
.
An
ea
sy t
o r
un
po
ssib
ilit
y t
o r
un
an
d a
cce
ss R
EA
CT
ION
fe
atu
res
insi
de
th
e G
P s
urg
ery
is
ava
ila
ble
.
Co
nti
nu
ou
s
pro
fess
ion
al
care
6.2.4 Implications for REACTION Platform Technology
Summary
The following list summarizes the requirements for the reaction platform which are related to technical solutions:
• Structured documentation of all data assessed by nurses and physicians (RDMM-68, RDMM-56, RDMM-57, RDMM-92)
- Management of clinical data collected during different types of patient encounters (visits, phone calls or other virtual visits): (data set should be specified according to clinical guidelines and European standardisation attempts
6)
o Diagnoses, co-morbidities, complications
o Current status: Objective and subjective
o Current measurements: Blood pressure, Cholesterol, Creatinine, etc.
o Eye exam, foot exam
o Therapy (Insulin Therapy, other glucose lowering therapy, other medication)
o Self management support / lifestyle modification: Structured diabetes education, dietary advice etc.
o Management of complications (RDMM-67)
- Reason for ending monitoring within REACTION (RDMM-69)
- Data model for health status information (populated during patient visits and by analysis of remote monitoring data) (“Personal Health Status Model”) (RDMM-45)
- Personalised care plan
- Consider patient’s preferences, wishes and decisions (RDMM-131)
- Management of referrals to and responses from other physicians (summary letters, if possible in a structured way) – via EHR interface (RDMM-132)
• Management of telemonitoring data (RDMM-133)
o Visualisation of telemonitoring data for professionals
o Visualisation of telemonitoring data for patients
• Allow configuration of workflows and documentation (e.g. which data fields should be documented how often / at which stage in the care process) (RDMM-56, RDMM-57, RDMM-92, RDMM-61, RDMM-58)
• Definition of “workflows” for patients which interact with physician workflows (e.g. different monitoring schemes for different patients) (RDMM-38)
• Definition of alerts and reminders for healthcare professionals (physician, nurse) (RDMM-42)
• Decision support for the insulin dose (RDMM-60, RDMM-51)
6 www.eubirod.eu – EUBIROD – European Best Information Through Regional Outcomes in Diabetes
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 75 of 85 DATE 2010-08-31
• Individually distribute roles and tasks among the multidisciplinary health care team (RDMM-93)
• Store and retrieve reports of clinical case conferences (RDMM-93)
• Models and rules for long term risk assessment (RDMM-44)
Excursion7: Level of integration and candidate user interfaces in primary care
There are several possible scenarios for making REACTION functions available to healthcare professionals.
• Integration in EPR: The integration of REACTION functionality into the EPR software would help to achieve acceptance of the system by the professionals because of the low entry barrier. However, as there is a multitude of EPR systems available, integration is not a very scalable solution. (RDMM-129)
• Client access to central server: This scenario executes no REACTION software in the GP surgery. The REACTION functionality is provided by a central server which is accessed by a remote client (e.g. Web interface). Access is easy to establish for any number of participants, but no access to any local resources such as EPR, laboratory and other devices is possible. (RDMM-3, RDMM-23, RDMM-26)
The following solution is a trade-off which can overcome the disadvantages of both above scenarios: (RDMM-130)
- REACTION application is executed in the surgery and independent from the EPR (recommendation server-based for multi-user environments)
- Communication with other components of the REACTION platform, mainly the central server, take place via Web Services
- Communication with EPR and other data sources inside the local network (via HL7 etc.)
- If an EPR manufacturer is interested in integration of REACTION features, this can be done via Web Service calls to the local REACTION application any time. (RDMM-129)
Candidate user interfaces are therefore both a web browser UI and an application client UI. Application clients used to be more user-friendly as they allowed development for higher interactivity- This has recently changed and various web toolkits allow almost the same level of interactivity in the browser. Therefore a decision has not yet been taken.
A user interface for a mobile device from the current point of view is an add-on which only makes sense after an interface on a stationary computer has been implemented.
Excursion: Candidate user interfaces for patients
Patients should be provided with a user interface that requires no installation (Web UI) or is very easy to install (mobile device App). Some reaction features are more suitable for a stationary PC, others of course are more useful or even exclusively useful if they are provided on a portable device. For this reason both interfaces will have to be provided for patients.
7 Subsections marked with Excursion show an approach how the outpatient prototype application can be integrated into the
REACTION overall architecture. They are partly out of scope of D4-3, but due to the dynamic process of finding a first architectural solution for REACTION initiated in D4.3, we decided to already present it in this deliverable.
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 76 of 85 DATE 2010-08-31
7. Conclusions
This chapter summarizes the results of this deliverable. According to the overall structure of the report the conclusion is divided into the REACTION Platform and the Application Prototypes. For every aspect of the data management model the main impacts are figured out.
7.1 REACTION Platform
Data Interface
• REACTION will implement a distributed system. From this it follows that the system architecture needs different interfaces for external and internal interfaces in order to exchange data.
• Several data interfaces will comply with various standards, primarily those intended for eHealth interoperability ((e.g. HL7, IHE-PCD01) and communication with medical devices (e.g. IEEE 11073).
• Following data interfaces have to be considered:
o External, i.e.,
� Interfaces to other health-care sub systems, including EPRs, demographic databases, or hospital information systems incl. laboratory information systems
� Interfaces to global services, like MS HealthVault and GoogleHealth
o Internal (inter component messaging and service invocation)
o Medical devices
o Persistent storage media
o Data entry/capture (for patients and carers)
Data Source (with focus on PAN/BAN)
In the REACTION platform patient data is collected from three different sources:
• Measurements from medical devices (e.g. glucose values, vital parameters)
• Manually entered data by the patient or a member of the medical team (e.g. insulin injections, patient questionnaires concerning physio- psychological conditions, medication, self management, lifestyle data, or measurements which are not automatically transferred)
• Data imported from external source (e.g. EPR/HIS, laboratory information system)
The BAN and PAN devices are responsible for collecting medical measurements of a patient, along with context information and environment factors. In order to use PAN/BAN for the REACTION data management following aspects have to be considered:
• Providing environment sensors or other ambient and background information for collecting of glucose, vital and context-related data.
• Contextualization of measured values, such as blood glucose values
• Collecting medical data which is not collected automatically and have to be inserted manually or inferred by other pieces of information like external knowledge base systems.
• Ensure interoperability, data consistency, privacy, low complexity, especially in the PAN/BAN network, and to decrease power consumed by the sensors
• Secure and accurate data transmission from the devices and sensors
• Faultless data transfer across the standards
• Endorsing plug and play device interaction
• Scalability for further changes to facilitate well functioning
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 77 of 85 DATE 2010-08-31
• A middleware should be implemented in a way to ensure seamless integration
Data Storage
Data storage is necessary in all distributed parts of the REACTION data management architecture (see Figure 2):
• Patient devices and REACTION AHD/Hosting Client measured values might not be possible to transfer to the server due to lack of connectivity and therefore data needs to be temporarily cached;
• REACTION DEVICE Hosting Server storage of measurements as a series of observations, each aggregating a measured value with its possible context data; storage of individual treatment plan of patients
• Data Mining / Risk Stratification storage of large sets of historical data for all patients under treatment (e.g. from EPRs or other external data sources) in order to analysis and create new knowledge about diabetes treatments
In order to store and retrieve data securely following data management functions have to be considered:
• Dynamic data structure (see below) in order to provide flexibly data fields for changing needs of data storage
• Provide mechanism for consistent and regular insertion, update and deletion of data
• Emphasis on data security and data access (see section 5.6)
Data Structure
• REACTION platform should be flexibly and support many types of disease management applications, i.e. support model driven architecture with functions based on formal models and rules, applications are generated from models
• REACTION platform needs flexibly data structures in order to consider the model driven architecture
• REACTION will be based on a service oriented architecture and will be deployed in a distributed manner, i.e. data structures have to be exchanged between components
• XML format and vocabulary will be used for expressing the data structures
Following data should be considered in the data structure:
• Data for mechanistic model and inpatient glucose control (e.g. administrative data, demographic data, medical history, laboratory data, external input)
• Data for personal health status profile
• Data fields for storage of case base
• Data for Primary Care disease management (e.g. outcome of clinical checks, medication, complications)
Data Semantics (including data presentation)
In order to support the semantic management of data and as a basis for knowledge management, REACTION will exploit semantic technologies. Following main aspects have to be considered in the data management model:
• Definition of a common ontology to refer to data, metadata, interfaces and models
• Necessary models (e.g. for risk assessment), action and event rules are defined and stored
• Relevant entries in the REACTION’s databases are annotated with semantic concepts
• A health status model is present; the care plan can be personalized
• An individual monitoring scheme can be defined for each patient
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 78 of 85 DATE 2010-08-31
• REACTION provides a knowledge discovery module to process unstructured information and store this information in the data storage for further processing
• Data can be visualized flexibly (context based) and with good performance to professionals
• A medical knowledge base will be built. It may contain the following elements:
o treatment algorithms and protocols
o guidelines represented in a computable way
o physiologic models (e.g. to calculate insulin dose)
o lifestyle models including the possible physiologic consequences
o risk models (take genetics, physiology, lifestyle, social environment into account)
o other schemes and algorithms (e.g. blood glucose patterns, if-then rules)
A detailed work on data semantics will be provided in the deliverable D4-2 Initial data structures, taxonomies and ontologies.
Data Security
The REACTION platform is organised in a decentralised manner, such that personal, medical information is transmitted and shared by several parties. Therefore, it is necessary that such data is transmitted, managed, and processed in a secure, trusted, and privacy-preserving way. The following requirements can be identified for the REACTION data management model:
• Confidentiality has to be guaranteed in order to allow medical devices to upload measurements (e.g. from patients’ to their doctor’s PC without anyone else being able to learn about these measurements.
• Authenticity of senders and recipients of medical data must be ensured
• Data integrity must be verifiable and the verification must be carried out before the data is added to the EHR
• Access to personal data will be given to authorised entities only
• Patient’s consent must be sought before any data processing can take place
7.2 Application Prototypes
Inpatient Glucose Control
Data Interface The inpatient prototype requires various interfaces to internal and external systems:
• Interface (e.g. HL7) to the patient demographic register of the hospital information system in order to enable the system to identify and manage patients on the ward
• Interface to lab data, especially glucose values, preferably based on HL7
• Interface to POCT device if glucose values cannot be transferred from the LIS to the prototype in time
• Interface to the Hospital Information System in order to import clinical data like medical history based on HL7
• Interface for user inputs to allow manual user entries
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 79 of 85 DATE 2010-08-31
Data Source Different data will be required in order to perform decision support for insulin dosing in the general ward:
• Administrative data such as sex, age, or assigned hospital bed
• Clinical information such as type of diabetes, co-morbidities, drugs and symptoms such as fever, infection, diarrhea, vomiting, or hypo- hyperglycemia
• Laboratory data like HbA1c, glucose values, nutrition and also context data (e.g. time of glucose measurement, device type)
Data Storage Data has to be stored within the inpatient environment in an adequate manner. Thus, the inpatient prototype should allow usual database operations like insertion, update or retrieval of data.
Data Structure In order to hold the data for the impatient pilot application, a dynamic data structure for data storage has to be implemented. Data fields should be flexibly defined. A suitable model could be the Entity-attribute-value (EAV) model.
Data Semantics The complex management of data, information and knowledge is an important feature of the inpatient prototype. The data management model has to consider data semantics in order to gain information and knowledge from source data for following applications:
• Mechanistic model and rules for insulin dose prediction
• Adaptable electronic fever/sugar chart that meet requirements of physicians
• Visualization of current "insulin on board" and "carbohydrates on board"
• Context management for clinical (lab) values
Data Security In the first development phase, the inpatient prototype will be fully embedded into the technical environment of the University Hospital of Graz. The hospital information system implements various mechanisms to ensure security and privacy of personal patient data. If the inpatient prototype is coupled with the REACTION platform, security mechanisms as summarised in Section 5.6.2 will be performed.
Primary Care Diabetes Management
The following list summarizes the requirements for the reaction platform which are related to technical solutions:
• Structured documentation of all data assessed by nurses and physicians
o Management of clinical data collected during different types of patient encounters (visits, phone calls or other virtual visits)
o Reason for ending monitoring within REACTION
o Data model for health status information (populated during patient visits and by analysis of remote monitoring data) (“Personal Health Status Model”)
o Personalised care plan
o Consider patient’s preferences, wishes and decisions
o Management of referrals to and responses from other physicians (summary letters, if possible in a structured way) – via EHR interface
• Management of telemonitoring data
o Visualisation of telemonitoring data for professionals
o Visualisation of telemonitoring data for patients
• Allow configuration of workflows and documentation (e.g. which data fields should be documented how often / at which stage in the care process)
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 80 of 85 DATE 2010-08-31
• Definition of “workflows” for patients which interact with physician workflows (e.g. different monitoring schemes for different patients)
• Definition of alerts and reminders for healthcare professionals (physician, nurse)
• Decision support for the insulin dose
• Individually distribute roles and tasks among the multidisciplinary health care team
• Store and retrieve reports of clinical case conferences
• Models and rules for long term risk assessment
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 81 of 85 DATE 2010-08-31
8. Table of Figures and Tables
8.1 Figures
Figure 1: Use Case Diagram ...................................................................................................................... 12 Figure 2: Data Management view of the REACTION architecture ............................................................. 18 Figure 3: From data to knowledge .............................................................................................................. 36 Figure 4: Use-Case Diagram for Inpatient Glucose Control ....................................................................... 52 Figure 5: Use-Case Diagram for Primary Care Diabetes Management ..................................................... 66 Figure 6: Draft architecture for REACTION (primary care) platform .......................................................... 83
8.2 Tables
Table 1: Definition of JIRA issue to map data management model requirement ....................................... 16
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 82 of 85 DATE 2010-08-31
9. References
(Wiegers2003) Wiegers K. E., (2003). Software Requirements. Redmond,
Washington: Microsoft Press.
(PowerTest2010) Micro Focus CaliberRM, Requirements Management Software:
PowerTest.com. Available at: http://www.powertest.com/software-
requirements-definition-management-micro-focus-caliber.html (last
accessed on August 12, 2010).
(Podeswa2010) Podeswa H., (2010). UML for IT Business Analyst, Second Edition: A
Practical Guide to Requirements Gathering Using the Unified
Modeling Language. Boston: Course Technology, a part of Cengage
Learning.
(Robertson2006) Robertson J., Robertson S. (2006): Volere Requirements
Specification Template – Edition 11. Atlantic System Guild Limited.
(MagicDraw2010) MagicDraw 16.8 features.
Available at: http://www.magicdraw.com/feature_list
(last accessed on August 19, 2010).
(Dinu2007) Dinu V. and Nadkarni P. Guidelines for the Effective Use of Entity-
Attribute-Value Modeling for Biomedical Databases. Int J Med
Inform. 2007; 76(11-12): 769–779.
10.
Appendix I
10.1
Draft Architecture of REACTIO
N Primary Care Diabetes Management Platform
Fig
ure
6:
Dra
ft a
rchitectu
re f
or
RE
AC
TIO
N (
prim
ary
care
) pla
tform
10.2 Questions related to Requirement Elicitation Process
Mobile Devices (BAN/PAN)
• Which sensors (data) will be available for REACTION PAN/BAN? • Which interfaces/standards do we need to communicate with PAN/BAN devices? • Which additional PAN/BAN-related information do we need for context management? • How can we secure/measure reliability of communication? Do we need data-buffer? • Which security-mechanism we need for data/communication? • Which feedback is generated on PAN, BAN or REACTION platform?
Middleware, internal communication (Hydra)
• How can devices be identified? • Is user interaction required as part of the middleware (e.g. patient consent for transmission?) • Does the middleware provide an API for applications on the mobile device? • What do we need for a context management system?
Core server infrastructure
• Which data is stored in the core server? • Which data (structures), thesaurus, ontology will be required? • What data (structures) do we need for Information Extraction from existing medical data? • How are activities triggered (e.g. data update, perform alarms, trigger events)? • How is data synchronised?
External communication
• What external resources we take into account? • What data do we need from external resources? • Which standards/interfaces do we need for external communication? • What data structure do we need for data transfer? • How can we secure time-critical data transfer from external resources?
Security
• How data privacy can be ensured? • How can REACTION securely transfer data? • What access-roles do we need?
In-patient glucose control
• How does the inpatient glucose control prototype communicate with the REACTION platform? What interfaces/standards do we need?
• What data will be transferred to the REACTION platform? • What services does the REACTION platform provide for inpatient glucose control
(e.g. electronic decision support)?
• What data from inpatient prototype will be stored in the REACTION platform? • How can we manage that physicians can work location-independently? • How can we implement multi-user support?
Primary care diabetes management
• How can the REACTION platform perform Data Monitoring? • Which interfaces do we need to GP-Systems? • Alarm-Handling? Support Reminders? What data structures do we need? • How can REACTION support glucose management for Type 1 diabetes?
D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590)
VERSION 1.2 85 of 85 DATE 2010-08-31
11. Appendix II: Complete set of Technical Requirements for a
Medical Data Management Model
The complete set of Technical Requirements for a Medical Data Management Model is listed in document “D4-3 Appendix II: Complete Set of Technical Requirements_V10.pdf”.
Recommended