D4-3 2010 08 31 Technical requirements for medical data ......D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590) VERSION 1.2 5 of 85 DATE 2010-08-31 1. Executive

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


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


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


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.


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.


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


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


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,


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.


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.


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


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:


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:


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


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


*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


Dependencies Other requirements with a change

effect


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


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.


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.


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.


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.


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.


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.



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.


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.


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


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,


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.


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.



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.


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



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


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.


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


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.


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.


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.


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.


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 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.


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


retrieved for composing the

fever/sugar chart. When

estimating the insulin resistance,

clinicians shall have access to this

information.


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


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.


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.



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.


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).



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.


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.



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.


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.


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.


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.


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.


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.


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.


VERSION 1.2 43 of 85 DATE 2010-08-31



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.


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.


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.


the REACTION Device

Hosting Server and the

EPR/EHR System MUST be

authentic (entity





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.





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.


provide data authenticity,

integrity, and confidentiality



Device Hosting Server and

the EPR/EHR System

SHOULD be authentic

(message authentication),

with integrity, and

confidential.


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.





VERSION 1.2 46 of 85 DATE 2010-08-31



Device Hosting Server and

the GP EPR SHOULD be

authentic (message




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.





the REACTION Device

Hosting Server and the GP

EPR MUST be authentic

(entity authentication), with




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.






the REACTION Device

Hosting Server and the

patient's/GP's web browser

MUST be authentic (entity





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.





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.


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.


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


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)


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


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


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.


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”.


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


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


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.


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


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


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


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)


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


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


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?


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”.

Documents

D4-3 2010 08 31 Technical requirements for medical data ......D4-3 Technical Requirements for Medical Data Management REACTION (FP7 248590) VERSION 1.2 5 of 85 DATE 2010-08-31 1. Executive