Embed Size (px)
Citation preview
Master's Programme in Health Informatics
Spring Semester 2015
Degree thesis, 30 Credits
Investigation of Models for the integration of Patient Generated Health Data
within Swedish Multiple Sclerosis Quality Register
Author: Michael Fardis
Author: Michael Fardis
Main supervisor: Associate Professor of Medical Simulation, Nabil Zary, Department of Learning,
Informatics, Management and Ethics (LIME), Centre for Learning and Knowledge (CLK), Karolinska
Insitutet
Co supervisor: Postdoctoral fellow in Neuroepidemiology, Ali Manouchehrinia, Department of clinical
Neuroscience, MS-research group, Karolinska Institutet
Co supervisor: Dina Titkova, Business Developer Biosync Technology, MSc in Biomedical Engineering,
MSc in Bioenterpreneurship
Examiner: Andrzej Kononowicz, Department of Learning, Informatics, Management and Ethics (LIME),
C7, Karolinska Institutet
2
Affirmation
I hereby affirm that this Master thesis was composed by myself, that the work contained herein
is my own except where explicitly stated otherwise in the text. This work has not been
submitted for any other degree or professional qualification except as specified; nor has it been
published.
Stockholm, May 18, 2015
__________________________________________________________
Michael Fardis
3
Master's Programme in Health Informatics
Spring Semester 2015
Degree thesis, 30 Credits
Investigation of Models for the integration of Patient Generated Health Data within Swedish
Multiple Sclerosis Quality Register
ABSTRACT:
Background: Healthcare is transformed by the usage of new technologies, like Wearable
Devices (WD). Patient generated health data (PGHD) from WDs could be found useful in the
management and the research of a chronic disease, like Multiple Sclerosis (MS)
Objective: The objective of the study was to propose a model for the import of PGHD from WDs
to the MS Quality Register (MS QR), the main resource for research on MS in Sweden. The study
focused both on the medical data that is needed and on the technical challenges that exist in
such an implementation.
Methods: Design Science was adopted as a methodology. The context of the study chosen was
the MS QR. Participants were interviewed for the technical part and a questionnaire was
delivered in order to find the most meaningful PGHD for MS QR. Based on the results, an
artifact was created and evaluated from the perspective of the MS QR stakeholders.
Results: The survey was answered by 35 healthcare professionals. The results reveal the
difficulty of tracking a disease like MS using just WDs. The interviews revealed several
challenges and opportunities, like the legislative or organizational difficulties, but also the
opportunities that appear with initiatives towards healthcare innovation. The evaluation
triggered a simplification of the technical integration model, showing that simple solutions
could solve complex problems.
Conclusion: The import of PGHD in MS QR, is possible in technical terms. Applications should
also be added together with WDs monitoring. The choice of model to use, is strongly related to
how the data is used within the organization.
Keywords: Multiple Sclerosis, Patient Generated Health Data, Wearable devices, Quality
Register.
4
ACKNOWLEDGEMENTS
To everyone that helped me for the writing of this thesis, interviewees and survey participants.
To the people of the Multiple Sclerosis Quality Register, Leszek, Hakan, Katharina, Ali for all
their help and their answers.
To Pär for his valuable input in the study
To my supervisors, Nabil, Dina, Ali
To Bjorn and Dina, for giving me the opportunity to work for my thesis at Biosync and get
experience in a real working environment
To my family, without their support I wouldn’t have made it here today
To my friends for being next to me through all the process of the thesis writing
To Konstantinos Margaritis, for believing in me and supervising my bachelor thesis in
Bioinformatics
To everyone who has been advising me and helping me go on with the correct decisions
5
CONTENTS Abstract ......................................................................................................................................................... 3
Acknowledgements ....................................................................................................................................... 4
Abbreviation List ........................................................................................................................................... 7
Table of figures ............................................................................................................................................. 8
1. Introduction .......................................................................................................................................... 9
1.1 About Multiple Sclerosis ............................................................................................................. 10
1.1.1 Factors affecting MS ........................................................................................................... 11
1.2 About the Swedish Multiple Sclerosis Quality Registry .............................................................. 12
1.2.1 National Quality Registry of Sweden .................................................................................. 12
1.2.2 Swedish Multiple Sclerosis Quality Registry ........................................................................ 13
1.2.3 MS QR and research ............................................................................................................ 13
1.3 Sources of PGHD ......................................................................................................................... 14
1.3.1 Wearable devices and sensors ............................................................................................ 14
1.3.2 Mobile applications ............................................................................................................. 15
1.4 Feedback of PGHD into healthcare applications ........................................................................ 15
1.5 Technical aspects of integrating PGHD to healthcare data structures ....................................... 16
1.5.1 The model to be followed .................................................................................................... 17
1.5.2 Capturing of PGHD .............................................................................................................. 17
1.5.3 Uploading of PGHD to a storage repository ........................................................................ 18
1.5.4 Interoperability between PGHD stored in the storage repository and healthcare data
structures. ........................................................................................................................................... 18
1.6 Problem description .................................................................................................................... 18
1.7 Aim, objectives and research questions ..................................................................................... 19
Objectives: .......................................................................................................................................... 19
Research questions: ............................................................................................................................ 19
2. Methods to be followed...................................................................................................................... 20
2.1 The Design Science Methodology ............................................................................................... 20
2.2 Data analysis ............................................................................................................................... 24
2.2.1 Questionnaire ..................................................................................................................... 24
2.2.2 Interviews ............................................................................................................................ 25
2.3 Evaluation of proposed model .................................................................................................... 25
2.4 Ethical considerations ................................................................................................................. 25
3. Results ................................................................................................................................................. 27
6
3.1 PGHD perceived as valuable to integrate within SMS registry ................................................... 27
3.1.1 Relevant clinical signs and factors ...................................................................................... 27
3.1.2 Additional comments and recommendations .................................................................... 28
3.1.3 Answers between different specialties ............................................................................... 28
3.2 Interview Results ......................................................................................................................... 29
The MS QR – IT needs and current situation ...................................................................................... 31
3.2.1 Challenges about transfering data from the EHR and DS DB to the MS QR ....................... 32
3.3 The proposed models ................................................................................................................. 33
3.3.1 The 3 proposed models....................................................................................................... 33
3.4 Evaluation of the proposed models for the integration of patient generated health data in MS
Quality Register ....................................................................................................................................... 39
3.5 Evaluation of the proposed models according Design Science evaluation criteria .................... 41
3.6 Proposing a feasible model for the implementation, after the re-design according to the
evaluation of MS QR ............................................................................................................................... 41
4. Discussion ............................................................................................................................................ 43
4.1 Challenges related with MS ........................................................................................................ 43
4.2 About the evaluation of the models from MS QR ...................................................................... 45
4.3 About cloud computing .............................................................................................................. 45
Challenges and opportunities of using cloud solutions in healthcare ................................................ 48
4.4 Challenges and opportunities of integration of PGHD in the Swedish reality ............................ 48
4.4.1 Tjänsteplattformen and Health Information Plattform ...................................................... 48
4.4.2 Law limitations .................................................................................................................... 49
4.5 Generalization ............................................................................................................................. 50
4.6 Future research ........................................................................................................................... 50
4.7 Limitations................................................................................................................................... 51
5. Conclusion ........................................................................................................................................... 52
6. References: ......................................................................................................................................... 53
Appendices .................................................................................................................................................. 61
Appendix 1 .............................................................................................................................................. 61
Appendix 2 .............................................................................................................................................. 62
Appendix 3 .............................................................................................................................................. 66
Appendix 4 .............................................................................................................................................. 68
Appendix 5 .............................................................................................................................................. 69
Appendix 6 .............................................................................................................................................. 71
Appendix 7 .............................................................................................................................................. 77
7
Appendix 8 .............................................................................................................................................. 82
ABBREVIATION LIST
BMI: Body Mass Index
DB: Data base
DS: Decision Support
EHR: Electronic Health Record
HIP: Health Innovation Platform
IT: Information Technology
MS: Multiple Sclerosis
PGHD: Patient Generated Health Data
QR: Quality Register
WD: Wearable Device
8
TABLE OF FIGURES Figure 1; Diagram of different MS types. How MS deteriorates through time. Available from:
http://www.mattsms.com/2013/07/what-are-4-different-types-of-multiple.html .................................. 11
Figure 2: Design science research cycles (Hevner et al, 2007) ................................................................... 20
Figure 3: A process model for Design Science Research Methodology (Peffers et al, 2008) ..................... 22
Figure 4 Background of the participants of the study ................................................................................ 23
Figure 5 Necessity of factors affecting MS, in order of preference ............................................................ 27
Figure 6: Correlation of answers between different specialties ................................................................. 28
Figure 7: Interview results .......................................................................................................................... 29
Figure 8: Model 1 Data end up in the MS QR, through an intermediate cloud storage and
tjänsteplattform .......................................................................................................................................... 33
Figure 9: Model 2 Data end up in a DB parallel with MS QR DB, since they follow the same flow as
before, but without being validated from a doctor in Decision Support DB .............................................. 34
Figure 10: Model 3: Data are entered directly in the Patient DB and end up in MS QR DB ....................... 34
Figure 11: First step of the implementation ............................................................................................... 35
Figure 12: Second step of the implementation - Model 1 .......................................................................... 36
Figure 13: Second step of the implementation - Model 3 .......................................................................... 37
Figure 14: Final step of the implementation - Model 1 .............................................................................. 38
Figure 15: Final step of the implementation - Model 2 .............................................................................. 38
Figure 16: Schematic representation of feedback given about the models and PGHD proposed ............. 39
Figure 14: Model proposed after the evaluation with MS QR ....................... Error! Bookmark not defined.
Figure 17: Implementation model after the evaluation with MS QR ......................................................... 42
Figure 18: Cloud computer architecture(86) .............................................................................................. 46
Figure 19: Different cloud models(87) ........................................................................................................ 47
Figure 20: The way tjänsteplattform tries to alter Swedish healthcare structure
(http://www.inera.se/TJANSTER--PROJEKT/ICC-Integration-Competence-Center/) ................................. 49
9
1. INTRODUCTION
Healthcare as we know it, is evolving during the last years. Information Technology (IT) is
becoming more and more used in the healthcare processes and that has a significant impact in
the way that hospitals and other health providing structures work.
The usage of new technologies like wearable trackers, other sensors that allow patients home
monitoring and also mobile applications that can store and transmit other patient data, are a
new category of tools which starts to be used in healthcare. This new reality has created a novel
category of patient data, the so called Patient Generated Health Data (sometimes also referred
into literature as Patient Generated Health Information).
Patient Generated Health Data (PGHD) as defined by Shapiro(1), are “health-related data,
created, recorded, gathered, or inferred by or from patients or their designees (i.e., care
partners or those who assist them) to help address a health concern”. PGHD amongst other can
include:
Health & treatment history
symptoms
biometric data
lifestyle choices
other information
The two main differences between the PGHD and data that are generated in a hospital setting
are:
1. Patients are the only responsible for capturing or recording these data.
2. Patients are responsible for sharing their data with the healthcare sector and/or other
stakeholders.
PGHD work as a complementary source of data, for healthcare providers. The main advantages
that can come from the usage of PGHD are 4(2):
1. Provide important information about patients between medical visits.
2. Gather information on an ongoing basis, rather than only at patients’ visits.
3. Provide information relevant to preventive and chronic care management.
4. Potentially improve patient safety, e.g. by gathering information on medications taken
and possible allergies/interactions.
Wearable Devices (WD) and in general home monitoring sensors, could be considered as the
main source of PGHD. Also the usage of mobile applications that could record information
entered by patients, could give useful information about factors that cannot be measured by a
device or a sensor.
10
Not many healthcare structures use PGHD yet, but their potential could be numerous.
Especially when it comes to chronic diseases like Multiple Sclerosis (MS), PGHD could be a great
assistance for better patient management and research on the disease.
In the following pages, there will be an introduction to the disease of Multiple Sclerosis and the
work of the Swedish MS Quality Register. There will be also a literature review on existing WDs
and other sensor solutions for patient monitoring, information about pilots and initiatives
which try to import PGHD in healthcare and finally, the technical challenges that exist in the
effort to achieve an implementation like this.
1.1 About Multiple Sclerosis The usage of PGHD could be of big importance when it comes to chronic patients or older
individuals.(3)(4) That kind of a chronic disease, is Multiple Sclerosis. In MS the immune system
attacks the myelin that covers the nerves. This damage leads to a disruption of the
communication between the brain and the rest of the body.(5) According to Schumacher et al.,
the episodes can be acute or developing slowly scattered over a period of time. There may be
relapses that appear and disappear through time, but in the long term MS could lead in
permanent disability.(6)
There is yet not known cause of MS. There is also no medical treatment for the disease, but just
medication that could alleviate symptoms, which is also problematic since side effects or Drug
to Drug Interactions have been recorded. Also, MS symptoms can vary from each individual.(7)
There are four different types of MS patients(8):
1. Relapsing-Remitting MS (RRMS), which is the most common case of MS. Patients with
RRMS face relapses, with appearance of new symptoms.
2. Secondary-Progressive MS (SPMS), where symptoms are getting worse over time, with
or without relapses and remissions.
3. Primary-Progressive MS (PPMS), which occurs in about 10% of MS patients. In PPMS
symptoms worsen slowly without relapses and remissions.
4. Progressive-Relapsing MS (PRMS), which is rare and is characterized from acute relapses
but no remissions. The disease keeps worsening and is even more difficult to confront.
11
Figure 1; Diagram of different MS types. How MS deteriorates through time.
Available from: http://www.mattsms.com/2013/07/what-are-4-different-types-of-multiple.html
Given all the factors listed above, it is obvious that the only solution for an MS patient is to have
a better management of the disease, which eventually will lead to a better quality of life. There
are several factors that should be taken into account when we talk about MS management. The
most important will be presented here.
1.1.1 Factors affecting MS
Stress is a factor that is said to cause relapses to MS patients.
Patients themselves believe that stress can affect possible relapses.(9)
Stress can be considered as a deteriorating factor when it comes to relapses.(10)
Different kind of stress can have positive or negative effects to the patients.(10)(11)
Patients managing their stress levels, could have less possibilities for future relapses and
a better life quality.(12)(13)
Almost all the articles suggest that more research should be done on the correlation between
stress and relapses in MS.
A lot of MS patients are facing sleeping problems.
Insomnia, narcolepsy, sleep disordered breathing, circadian rhythm disorder, restless
legs syndrome (RLS) and rapid eye movement (REM) sleep behavior disorder.(14)
Pain could cause sleeping disorders.(15)
Closely associated with fatigue and low life quality(16)(15)(17)
12
Fatigue is another prevalent problem that MS patients have to face. Measured by the fatigue
severity scale (FSS).(18)
Closely correlated with sleeping disorders.(16)
Can be caused from MS or from comorbidities.
Can be triggered from Central Nervous System, immunological reasons, depression or
other psychological factors.(17)
Till now there are some initiatives for monitoring MS patients with the usage of WDs or
sensors, but they are mostly focused on steps counting with the usage of accelerometers.(19)
Even if this kind of measurement is a simple one, there are studies which suggest that step
counting can give valuable information for MS patients.(20)(21) More sophisticated studies
about gait and balance measurements exist too, but they are mostly of clinical
interest.(22)(23)(24) These initiatives can be considered as a good start, there are though more
other factors that are of importance when it comes to MS management, such as the
psychological condition of the patient which was mentioned above.(25)(26)
1.2 About the Swedish Multiple Sclerosis Quality Registry
1.2.1 National Quality Registry of Sweden
Sweden has a long history of keeping records. This could not change in today’s era of
computerization, where Sweden is again a pioneer. One record keeping structure like this, is
the National Quality Register. The National Quality Register is a set of registries and other
quality tools, which have as a target to further improve the quality of care given to the Swedish
population.(27)
The definition for a QR could be: “an automated and structured collection of personal data that
were initiated with the purpose to systematically and continuously develop and safeguard
quality of care”.(27) QRs can be national or regional, depending from which caregiver the data
have been collected from. When a QR is fully developed, it can allow comparisons between
hospitals or clinics on a national or regional level, or also comparisons between counties. There
can also be measurable outcomes regarding what has been achieved for the patients’
healthcare services in that county.(27)(28)
The professionals that lead each QR, are mainly physicians. Other health professionals may
participate as well, like registered nurses, psychologists or physiotherapists.(28)
The patients should be informed that their data will be used for the needs of a specific QR and
in case they disagree they can “opt-out”. The patient data within the QR, are used for research
purposes and each researcher who wants to use these data, should get an ethical approval in
advance. (27)(28)
13
The National QR has as a vision to improve the ongoing research and knowledge base for
specific diseases, by working with real patients data. The ultimate goal is taking advantage of
each patient’s personalized information to ultimately improve the healthcare services given to
the whole population of Sweden.(27)
1.2.2 Swedish Multiple Sclerosis Quality Registry
A registry that is strongly related to the MS management, is the Swedish Multiple Sclerosis
(SMS) quality register.(29) In Sweden there are about 18.000 patients that suffer from MS.
Since 1996, the SMS QR is gathering information for about 13.700 of the MS patients across
Sweden. More patients are inputted, with a rate of 10% every year. There are 60 health units
across the country that cooperate with the MS QR. (30)
The purposes of the MS QR include(29):
To contribute to MS care in Sweden, so that is keeps a high quality and it is evenly
delivered across the country.
To ensure that the current guidelines for MS treatment are correctly used.
Evaluate the long-term effect of modern, disease-modifying treatments, on the
progression of MS.
To create and disseminate new knowledge about MS, through research.
A synopsis of the records that the QR is keeping for Multiple Sclerosis are the following(30):
Basic Data
Visit
Neurological Rating Scale EDSS
Onset and diagnosis
Treatment information
Relapses
MRI exams
Laboratory analysis
Body mass index, BMI
Cerebrospinal
Function Scales
Quality of life indicators
Working capacity
Rehabilitation process
1.2.3 MS QR and research
One of the purposes of the Neuroregistry and of MS QR in specific, is research. The collected
data are used in order to generate new knowledge about the diseases that are being tracked.
Information for patients in the MS QR are entered in a more systematic way in relation to a
normal patient. There are additional information needed for the MS QR and thus the caregiver
is in a way “forced”, to enter more detailed data. That makes diagnoses in in the QR safer, more
accurate and more complete. In that way the data in the QR have a higher quality, which
provides also increased usability for both caregivers and researchers. All patients’ data in the
QR are anonymized.
14
1.3 Sources of PGHD
1.3.1 Wearable devices and sensors
During the last years, there is a huge burst in the usage of WDs. It was estimated that, only in
2014, 90 million WDs would have been sold worldwide.(31) One simplistic definition for a WD
could be, an electronic item that can be worn on the body of the user.(32) Today there are
wearables devices that can be worn literally everywhere on the body, with the majority of
them, being wristbands or smart watches, with head wearable devices coming second.(33)
WDs measurements can become a big source of PGHD. WDs use accelerometers, pedometers,
geographical locators and other sensors, in order to capture different kinds of data. A lot of big
companies have entered the market, like Apple with the Apple Watch (34), Google Glass (35),
Nike Fuelband (36) or Samsung Gear, which is a full series of wearable products(37).
Wearable sensors can measure biometric data in real, not only for vital signs, such as ECG,
respiration rate, blood levels or skin temperature but also stress levels, mood, sleep patterns,
galvanic skin response, physical activity, etc.(38)(39)(40)
Assets
The biggest asset of PGHD, is that they can be collected automatically from the patients
themselves, in several time intervals or continuously and most important, the whole process is
done from the patient’s home without the need to visit the hospital.(39) Patients from their
side, do not need to leave their home and in the long term, they can have a more independent
life.(4)(40) Health personnel can have a constant image of the patient, without having physical
contact with him. The latter also means that nurses and doctors have less workload.
A glimpse of the benefits that distant monitoring solutions can give, can be shown from studies
contacted to patients with cardiac conditions. Patients following home monitoring, had 6 days
less hospitalization(41), while the chances of hospitalization decreased 9fold after participating
in the monitoring program(42) and mortality rates were reduced more than 50% compared to
patients following traditional healthcare methods(43).
Existing solutions
According to a literature review from 2008(44), the majority of the solutions existing in that
time, were mostly home monitoring solutions. The body subsystems that were tracked, in
descending order, were the cardiovascular, the nervous and finally the respiratory system.
According to Chan et.al.,(40) the diseases or disabilities that a WD can help with, are numerous.
WDs can be used in chronic disease monitoring such as cardiovascular diseases, diabetes
mellitus, respiratory diseases like COPD and in some cases they may also be used for cancer
15
prevention.(45) The most commonly used vital signs that are measured from a patient are pulse
oximetry, body and skin temperature, heart rate, blood pressure, ECG and respiration rate.
Diseases tracked Other possible measurements
Cardiovascular disease (4)(44) Stroke rehabilitation (46)
Diabetes mellitus Sport science (40)
COPD and other respiratory diseases Fall detection (4)
Neurological diseases (Epilepsy,
Parkinson’s disease, Quadriplegia)
Body posture (47)
Gait analysis and motion control (48)(49)(50)(51)
Home activity monitoring (4)(52)
Sleep monitoring (53)(54)(55)(56)
Location tracking
Medication intake (4)
Clinical research (39)(57)(58)
Cancer prevention (45)
The aforementioned solutions, include WDs and other sensors, used for home monitoring, such
as adherence to medication solutions. Another set of sensors called also environmental
sensors, refers to solutions that can be found in the greater area of the house of the patient,
such as cameras and fire or fall detectors.
1.3.2 Mobile applications
Another way to collect PGHD is the usage of applications for smartphones or tablets. Patients
will be able to use applications that will be built on demand and collect specific data. Forms,
questionnaires, input of daily habits or activities and other data that cannot be tracked with a
sensor, could be collected and give an image of the everyday life of a patient.
In contrast with the sensors that have a constant flow of measurements, the applications need
the patient to fill in the data. Consistency with updating the application with new data, is one
issue to be taken into account and is solely based on patient’s will.
One big advantage of the usage of an application though, is that it can measure literally
anything that could be of interest from a patient. Sensors can track measurable data from a
patient, but with the usage of custom applications, able to get input for non-measurable
parameters, it is possible achieve a full scale monitoring of a patient’s state.
1.4 Feedback of PGHD into healthcare applications Data from WD can possibly be useful for healthcare, but they are not yet incorporated into the
context of healthcare applications such as EHRs or Quality Registers. An obstacle to using
PGHD, is that till now the flow of the medical data was from the patients to the doctor and then
to the EHR. Now this flow is differentiated, since the patient creates health data. The current
16
structure of healthcare systems, does not allow the import of data from a source outside a
clinical context. There are though some initiatives that have tried to import PGHD within
healthcare.
CONDUIT-HID is one initiative that was taken in the US in 2012 and it was about hypertension
measurements in diabetic patients.(59) The project tried to send the patients electronic blood
pressure measurements, to the EHR that was used for them (designed from Epic). In order to
succeed in this effort, the Microsoft HealthVault(60) was used as a data storage between
patients and the EHR. In this study, the researchers tried to find an inexpensive way of
uploading a simple medical measurement to an existing health data structure, as an EHR.
The patients had to use an OMRON blood pressure monitoring device and upload their data to
Microsoft HealthVault. PGHD were then synchronized between Microsoft HealthVault and Epic
EHR. If the nurses found that the readings were proof of a dangerous situation or the patients
haven’t uploaded any data for the last month, they were getting in contact with the patients.
The study is interesting, not only because it tries to synchronize the data between the patients
and the EHR, but it also because it tries to find out generalizable problems that could arise from
the process of uploading PGHD directly to an EHR.
There is also another initiative that takes advantage of a new feature of the iPhone6, Healthkit.
Healthkit is expected to gather all the information of the health related and fitness applications.
The user can have a full image of his health state and choose if and with whom he wants to
share these data with.(61) Epic will be using this capability of the new iPhone 6, in order to
input patient data from health apps into its EHR, but there is still not published research behind
this initiative.(62) Apple has launched also Researchkit, which will use iPhone apps in order to
gather users’ data and use them in medical research.(58)
1.5 Technical aspects of integrating PGHD to healthcare data structures The initiatives stated above are interesting, they are lacking though some important
background on how the technical process of data capturing, storage and sending was done. In
order to establish a properly working system that will store PGHD, there are several design
decisions that should be made and steps that should be taken before going forward to a full
scale implementation.
According to a recent study which proposed a model for the integration of PGHD in an EHR(63),
there are three pillars, that need to be clarified, in order to succeed such an implementation:
1. The PGHD of mutual interest for patients and medical personnel
2. The data flow model from patient to the QR
3. The standards that must cooperate through all this journey.
This flow of data is very easily described in a bullet form. In order to make it happen though,
there is a number of modeling, standardization and interoperability issues that should be taken
into account.
17
The question of the data that are of mutual interest was discussed above and will be evaluated
through asking the medical professionals for their opinion about the results from the MS work-
group. In the following pages, there will be a presentation of the rest of the challenges
regarding the gathering of the data their transfer and the storage in healthcare databases.
1.5.1 The model to be followed
The initiatives that were mentioned in the previous part, do not send data directly to an EHR,
but they are using intermediary applications. CONDUIT-HID store PGHD in Microsoft
HealthVault, while Epic uses Healthkit’s features for storing and forwarding data to their EHR.
Till now there are no initiatives, where PGHD are sent directly to healthcare data structures,
either it is a QR or an EHR.(1) The proposed models regarding the utilization of PGHD(63),
suggest the usage of intermediary stations. These stations can either be those presented above
or patient health records, administered and maintained by the patients themselves.
1.5.2 Capturing of PGHD
In order to capture PGHD, the user should send the collected data to an external device
(smartphone, tablet, pc, dedicated hub). The connection with that device can be done either
wirelessly (e.g. infrared, Bluetooth, Wi-Fi), or by cable (e.g. usb). The standard that has been
developed for such implementations is ISO/IEEE 11073.(64) Devices which follow this standard,
can connect automatically (plug-n-play) and in real time, with any external device and start
exchanging data. In Appendix 1, there is a list with all the medical devices that can be certified
to follow this standard.
Bluetooth offers the Health Device Profile (HDP)(65), especially for connection of medical
devices, while ZigBee(66) is another protocol which allows electronic devices that are located in
a small distance, to communicate seamlessly with each other. Another initiative for certifying
WD interoperability is the Continua Alliance. Continua is an industry driven alliance, which
provides a standard for communication between the user’s gateway and data uploading
interfaces1 of third party storage repositories. All the aforementioned initiatives for
interoperability, are based on the ISO/IEEE 11073 standard.
Within the Swedish context, Telia offers a solution for home monitoring, where a hub or a
smartphone is collecting all the information that comes from WDs and sensors and then
forwards it in an intermediary storage repository.(67) This project, called Telia Healthcare,
follows Continua guidelines.
1 . Data uploading interface may refer to a vendor-specific communication protocol between the user’s gateway and the storage repository
18
1.5.3 Uploading of PGHD to a storage repository
The sending of the data to an online storage repository can be done either by following an
already existing solution for healthcare data transmission, like Continua, or by treating PGHD as
regular data and do not use a specific health-related protocol. The latter is not a good solution
when it comes to the handling of patient data
One important feature that may not be taken into account, is that PGHD should have a time
stamp and an identification, in order to know: 1) who is the patient that transmitted these data,
2) when were these data transmitted and 3) what data are these (e.g. for what kind of disease
etc.). This authentication process is an important first step for the correct PGHD flow.(1)
1.5.4 Interoperability between PGHD stored in the storage repository and healthcare
data structures.
Once data are stored in an intermediate repository, they are not necessarily ready to be
transmitted to an EHR or a QR. Standards interoperability is the biggest issue that should be
addressed here. Since PGHD are stored in an intermediary location, in order to be sent further
to a QR or an EHR, some minimum interoperability issues should be fulfilled.
Units of measurement and the coding/terminology of the disease must be compatible with
these of the EHR/QR. There are standards that are followed in disease coding/terminology and
the two more popular are SNOMED-CT(68) and ICD-10(69). PGHD should follow one of these
two terminologies, ideally the one that is used from the EHR/QR.
EHRs are following two main standards, HL7 and OpenEHR. OpenEHR is based on the ISO
EN13606 standard for “Health informatics - Electronic Health Record Communication”.(70)
PGHD must also be interoperable with these standards. The problem is that data generated
from WD, follow the ISO/IEEE 11073 standard. There are studies today, that have proven that
interoperability of ISO/IEEE 11073, can be achieved both between HL7(71) and also
OpenEHR(72)(73), or with both of them in the same time(74).
1.6 Problem description
New technologies are transforming healthcare day by day. The usage of PGHD can become a
new tool in the healthcare arsenal, which can help with real time data from home monitoring of
the patients. These data can be utilized in many different ways mentioned in the introduction.
Patient home monitoring could help the most when it comes to chronic disease management.
MS is the disease that this study wants to focus on. Since it is an untreatable disease, it is really
important to invest on the best management of it, but also on the research that can lead to
treatment or better medicine in the future. Today MS QR is using all the data that were
19
mentioned above, which come mostly from visits of the patients, screening and lab exams and
digital forms of self-assessment of the patients.
PGHD could include numerous of measurements and as technology expands, more precise and
specialized sensors will be added. The technology for capturing and transmitting these data also
exists. PGHD could be of value for MS QR. Having patient data from their everyday life, could be
a huge change in the way that the research is done today. Several non-reachable parameters,
will be available for researchers in order to track patients’ state more closely.
The study will try to propose a way for bridging the gap between PGHD and research. This is the
first step that can be done, a step reachable and feasible to implement. This initiative of
integrating PGHD in SMSreg, can be considered as a pilot in order to show the vulnerabilities
and opportunities that may exist and propose the basis for a wider implementation in the
future.
1.7 Aim, objectives and research questions The aim of this study was to investigate appropriate models for the integration of patient
generated health data in MS Quality Register.
The ultimate goal of the thesis is to propose a feasible model for the proposed integration. This
study could be considered as a technical framework for the way that PGHD could be integrated
into the Swedish healthcare system in general.
Objectives:
Propose a model (artifact) for the integration of PGHD within the Swedish MS QR.
Upgrade the quality of MS QR by enriching it with PGHD.
Research questions:
Which set of MS PGHD would be perceived valuable from medical personnel and
researchers in order to be integrated within SMS registry?
What are the possibilities and challenges, in order to have a reliable and functional flow
of PGHD into the Swedish MS registry?
20
2. METHODS TO BE FOLLOWED
As mentioned previously on the aim section, the target of the study is not to give an answer to
the whole challenge of integrating PGHD in healthcare. This is a huge question that will take a
lot of effort and cooperation in order to have a functional model that will fit for all healthcare
data structures. The specific target, is to give a solution for the case of integrating PGHD within
MS QR. It will be a targeted solution that will fit on the needs of the specific organization.
The really specified target for the implementation in this specific context of MS QR, leads the
researcher to use the Design Science methodology. Design science initiated as a research
methodology that tries to solve Information Systems (IS) problems. Nowadays with technology
used more and more in every organization, a lot of the problems that arise could be solved
based on IS solutions. As defined by Hevner et al., design science creates and evaluates IT
artifacts (solutions) intended to solve identified organizational problems.(75) In our case the
organization that the study will focus on, is the MS QR and the problem that will be addressed
is this of integrating PGHD within MS QR. The artifact that can be considered as a solution, is
the model that will be proposed for the communication between WDs and MS QR.
2.1 The Design Science Methodology Design science research blends the existing knowledge base on the specific filed, together with
the organization environment reality, in order to give a solution for a specific problem. The
following figure explains how design science three cycles work:
Figure 2: Design science research cycles (Hevner et al, 2007)
The figure is more or less self-explaining on how design science cycles work. The environment is
where we have the MS QR people, the QR structure, the WDs that will be used. It is also where
we can find the problems and the opportunities within MS QR that can either pose difficulties
21
or help for the successful outcome of the study. The relevance cycle is where the target of the
study is initiated and also where the testing criteria are set. The meaning of the cycle, is that
the feedback from the testing of the artifact is given back to the organization in order to choose
whether new iterations are needed or the artifact can solve the problem defined.(76)
The rigor cycle, provides the prior knowledge that is needed in order to ensure that the artifact
will be an innovation.(76) It is an important part, since it is the rigor that differentiates the
building of an IT artifact though the process of design science, from building just one more IT
artifact.(77) In our case the knowledge base is the research that has been done previously and
the information regarding the existing tools (MS HealthVault, apple HealthKit) that can be used
as a part of the solution. Again, the rigor cycle returns this new knowledge that was produced
from the whole design science process, back to the knowledge base, in order to be used later
for other studies.(76)
The middle cycle is the heart of the design science research. It is where all the alternatives will
be evaluated against the requirements, until a satisfactory artifact is achieved. Requirements
derive from the relevance cycle, while the design and evaluation methods come from the rigor
cycle.(76)
The problems that can be solved with design science, the so-called wicked problems, are
five(75):
1. unstable requirements and constraints based upon ill-defined environmental contexts
2. complex interactions among subcomponents of the problem and its solution
3. inherent flexibility to change design processes as well as design artifacts (i.e., malleable
processes and artifacts)
4. a critical dependence upon human cognitive abilities (e.g., creativity) to produce
effective solutions
5. a critical dependence upon human social abilities (e.g., teamwork) to produce effective
solutions
The complex interactions among subcomponents of the problem and its solution, is the entry
point for this study. We are having an ecosystem that consists of several subcomponents like
WDs, PGHD and the MS QR. The question we are having is how all these will interact and
cooperate in order to give a model that will allow us reach a solution (artifact) for our target.
22
The process model that will be followed in order to conduct this design science research project
is the following:
Figure 3: A process model for Design Science Research Methodology (Peffers et al, 2008)
From the figure above we see that there are 6 phases that are the backbone of the design
science process and all of them, excluding the initial phase, are iterative. Also there are four
entry points in the process model, depending on the nature of the problem to be solved.
In order to achieve this, the study will be divided in three main tracks that will stick on the
process model pictured above. These three parts are the following:
need analysis (phase 2)
artifact building (phase 3-4)
case study (phase 4-6)
In order to reach the objectives mentioned above, the research approach that will be used is
the inductive one. The study will take into account the different opinions and views of all
stakeholders.(78) Since the subject of the thesis is spreading in many different areas (IT,
Healthcare, telecommunication), the range of the people that will be approached will be wide
and interdisciplinary. Doctors and IT experts from the MS QR, will give their perspectives based
on their knowledge and personal experiences on the subject. The study aims to gather enough
information from a lot of different angles, in order to understand all the aspects of such a
complex implementation.
The study will use both qualitative and the quantitative methods, in order to best fit the
different needs of each step of the study. Even if both approaches will be used, the study will
not end up following triangulation, since the data that will be gathered, will fall under different
areas of the study. The whole idea about the approach of the study, is better analyzed below.
23
The first phase of the identification of the problem and motivation, was done in the previous
section where the objectives and the aims of the study were analyzed.
The second phase is the need analysis, where both medical and technical aspects were taken
into account.
A electronic survey (Appendix 2) was be given to medical personnel in order to get the PGHD
that are most meaningful for the MS QR. This survey used the results of a workshop that was
held in 2014 and it was organized by Karolinska Innovationsplatsen in cooperation with other
MS stakeholders. In order to get the best audience, the survey was forwarded through MS QR
to the reference group of the registry. The participants were asked to rate 11 proposed
signs/factors. The ranking was a grade in the scale from 1 to 9, where 1 stands for “Very little
needed” and 9 stands for “Extremely needed”. The identity of the participants was 13 doctors,
12 researchers, 5 nurses and 5 other specialties related to MS.
Figure 4 Background of the participants of the study
Interviews (Appendices 3, 4) were initially planned to be done with stakeholders both from
medical and technical background. Since the researcher was not experienced neither on the
field of MS, nor WDs, there was one pilot interview scheduled first. The person that was
interviewed was a medical researcher. After that pilot interview though, it was obvious that a
common questionnaire cannot fit all needs, especially when it comes to people with different
backgrounds. It was then decided to interview only people with technical background, since the
medical related answers would be given from the survey. Finally there were 2 interviews:
Interview Background Input to the study
1 MS QR DB administrator Information about the technical part of the
MS QR
2 Telecommunication company Information about ongoing pilots and
structure of the PGHD platform used
The selection of participants for the interviews was done following the purposive sampling, in
order to have the opinion of selected people that are totally related with the MS QR and the
current pilots running. (79)
24
In phase three all the information of the survey and the interviews, together with the usage of
existing tools and technologies, were used to create an artifact. The artifact in our case is a data
flow model for the transfer of PGHD to the MS QR. The model will propose a data flow, in order
to achieve a feasible implementation, based on the Swedish reality.
In phase four there will be a demonstration of the model at the MS QR. Feedback will be asked
and a case study will be implemented.
In phase five there was an evaluation of the model used in the case study. There was an
evaluation on the feasibility of the artifact about the flow that the PGHD will follow before they
end up in the QR. The evaluation was done in cooperation with the MS QR and Carmona, the
company which is responsible for the administration of the MS QR database. There was a semi-
structured interview with two people working in MS QR.
Participant Background Took part in Phase 2 interviews
1 MS QR DB administrator Yes
2 Project manager – Swedish Neuroregistry
Development Coordinator
No
In phase six, the results of the study will be communicated to all possible stakeholders, like MS
QR and people that were connected with the study in any way, or even to a broader audience,
like other QRs or healthcare data structures, WD companies, or companies that wish to provide
solutions for transferring/storing PGHD. In case the results have scientific interest, they could
be also published in a scientific journal, in order to add more knowledge to the already existing
base.
In the graph below you can find the pairing of the thesis steps with the design science process
model phases:
DSRM phases
Study tracks
Identification
and motivation
Solution
objectives
Artifact
development
Demonstrati
on
Evaluation Communicati
on
Aim and objectives
Need analysis
Artifact building
Case study
2.2 Data analysis
2.2.1 Questionnaire
The ultimate goal of the questionnaire is not to have a deep analysis of the data, but to get the
most popular signs needed amongst professionals. The questionnaire will first clarify the way
25
that a person is associated with MS. Then the list of the proposed signs will be given for grading
from 1-9 according the necessity for the MS QR. In the last part there will be a free text section
and finally a section where the participants will be able to motivate why another sign should be
added. Data will be analyzed using statistic methods.(78) They will be grouped and frequencies
for each question will be given.(79)
2.2.2 Interviews
Interviews will follow the thematic content analysis method. The background of each
participant will be taken into account and different questions used for each one of them,
regarding their background. After that, data will be categorized by identifying similar themes in
the transcribed text.(80) The different opinions then will be interpreted by the researcher and
conclusions will be taken out, regarding the technical aspects of the implementation.
2.3 Evaluation of proposed model Design Science is still a relatively new scientific method. That makes the resources available for
it quite limited. In order to have a proper evaluation method related to the Design Science
methodology, the study will be based on a paper published in 2014.(81) The proposed model
from the study (Appendix 5) will be modified, in order to comply with the artifact proposed in
this study. That means for example, criteria that have to do with the performance of the artifact
in real circumstances, will not be included, since the model proposed here is theoretical.
This will be a qualitative evaluation. The evaluation will try to give answer to a series of criteria
and sub criteria. After the presentation and explanation of the model, it will be asked from the
participants to give any possible feedback they have for any of the criteria mentioned. The main
dimensions of the system that will be evaluated will be:
Goal – Does it reach its initial goal?
Environment – Can it cooperate with people/technology of the organization?
Structure – Is the artifact well structured?
Evolution – Ability to easily change/adjust to the new needs
2.4 Ethical considerations During all research stages of the study measures were taken to ensure beneficence, meaning
that the risk of harm for the participants must be the least possible.
The participants were well informed regarding the purpose of the study. In the interviews they
provided their perspective on the technical aspects of the implementation and also the
evaluation of the proposed flow model.
The participants in the interviews were clearly informed about the scope of the study and also
about the possibility to opt out and withdraw from the study at any point and having all the
material gathered from them permanently deleted.
26
Special attention was put on confidentiality and preventing private data identifying the
participants to be disclosed in any manner. The information gathered during the interviews and
the evaluation was anonymized and processed as such. The audio recorded material was
permanently deleted after transcription and data analysis.
All the questionnaires were also anonymized. There was no field that prompted to give
personal information and no access to the IP of any of the participants.
There were no patients participating in the study and no sensitive patient information were
used in any point of the study.
27
3. RESULTS
The Results section is divided in two stages. One for the survey regarding the PGHD that need
to get integrated within MS QR and a second one with the interviews from professionals,
related more to the technical part of the implementation.
3.1 PGHD perceived as valuable to integrate within SMS registry
3.1.1 Relevant clinical signs and factors
Figure 5 Necessity of factors affecting MS, in order of preference
In the chart we see the average rating that each factor/sign got. Possible relapses, Cognition,
Mobility/movement problems, Adherence to medication and Fatigue are ranked with more
than 8, rated as extremely needed. Bladder/bowel problems, Infections, Sleep disorders, Stress,
Weight tracking are between the values 5 and 8. Body temperature was the last amongst the
factors questioned. Detailed charts for each value can be found in Appendix 6.
Factor Average
1 Possible relapses 8.34
2 Cognition 8.34
3 Mobility/movement problems 8.29
4 Adherence to medication 8.23
5 Fatigue 8.06
6 Bladder/bowel problems 7.51
7 Infections 7.2
8 Sleep disorders 6.74
9 Stress 6.37
10 Weight tracking 5.46
11 Body temperature 3.54
28
3.1.2 Additional comments and recommendations
In the end of the questionnaire, there was a part that prompted the participants to add any
comments they wanted or to propose some more signals to be tracked. Here are the results of
the additional measurements proposed:
Menstrual cycle monitoring
Use of un-prescribed meds (painkillers or diet-supplements)
Pulse
Mood
Depression
Anxiety
Dysarthria
Aphasia
Dysphagia
3.1.3 Answers between different specialties
Out of the results of the survey, one interesting observation would be the ranking that different
professionals would give to the same signs.
In the graph we can see that there are not serious differences between the answers that are
1
2
3
4
5
6
7
8
9
Corellation between the answers of different specialists
Doctors Nurses Researchers Other Overall
Figure 6: Correlation of answers between different specialties
29
given from different specialists.
3.2 Interview Results The interview results are given here. All transcribed text can be found in Appendix 7.
In brief the main categories identified are the following:
Sensors to be used and interoperability with them
More and more sensors appear as time passes. It is not only the standards about
communicating, that should be taken into account but also the standards that are used in
healthcare. The challenge here for the platform that the WD will cooperate with, is double. The
platform should follow a set of standards that will allow it to be able to connect with different
sensors which follow the ISO-11073 standards. Finally all the captured data should be in a
format that will allow them to be transferred in the healthcare sector with the less
transformations to other standards possible. Continua seems to be a standard that enhances a
majority of these needed features.
Figure 7: Interview results
30
What is needed from the healthcare sector in order to fix a path for the transfer of PGHD in
healthcare DBs
Sweden has a really fragmented IT infrastructure, because of the way that the healthcare
system is organized in counties. There is an effort to alleviate this reality, with the development
of tjänsteplattform. This is a platform which tries to become an integration engine and will
allow to all these different systems cooperate with each other. MS QR is not yet connected to
tjnsterplattform, but it will happen in the future. Another issue, is to provide the correct
information that the medical personnel really needs. The data that are of interest, are declared
from the medical personnel and then there is a cooperation between tjänsteplattform, the
PGHD platform vendor and the company managing the EHR or QR. Tjänsteplattform is used in
today’s pilots and allows to get the desired PGHD from the company’s platform and push them
into the healthcare provider’s database.
Legislation / The way that data are forwarded to the healthcare sector in today’s pilots
Sweden has strict rules, both when it comes to the gathering of the data from patients, but also
for the storage of the data. So, in order to have any patient data stored from a company, there
should be an agreement with each individual patient, which will allow the company to gather
and store that patient’s data. The patient data should be stored in servers based in Sweden.
The legislation allows the patient to decide when he wants to transfer his data to the
healthcare sector. Even if PGHD are needed from medical personnel in certain intervals, the
patient cannot be forced to agree with that. The doctor can give an advice on when the PGHD
should be sent, but the patient is the one to make the final decision. Also the healthcare side
should agree that they want to receive patient data.
31
The MS QR – IT needs and current situation
How the data are entered in the MS QR today
The way that the data are entered to the MS QR, consists of 3 different DBs and it gets data
from multiple sources. The MS QR database (DB) is the final receiver of data that pre-exist in
the two other DBs. These three DBs run in parallel with hospitals’ EHRs and are used for all MS
patients across Sweden.
Patient BD: Contains forms filled by the patients. Data are anonymized but have a
unique identifier for every patient, linked with the identifier at the Decision Support DB.
Forms validated by the doctor and
forwarded to the Decision Support DB if
doctor approves. No consent from the
patient is needed in order to forward data
to the next DB.
Flow of data
Decision Support DB: Data here are not anonymized. Contains all the approved patient
forms, doctor’s input like diagnosis or comments, lab and screening exams like MRI. In
general it contains information that can be captured from patients’ visits. Doctor has to
input the data in DS DB manually, since there is no automatic connection with the EHR.
The data of the patients that have given
their consent, are tranfered to the MS QR
DB.
Flow of data
MS QR DB: Data are stored here for the purposes of the MS QR This DB contains all the
information of the previous DB, but anonymized. Patients who don’t want to share
their data, can opt-out.(28) MS QR DB, follows the ICD-10 terminology.
32
3.2.1 Challenges about transfering data from the EHR and DS DB to the MS QR
Non automated input of data from the EHR
There is no automatic way to enter data into the QR. All data should be put twice from the
doctor and the only way that there could be a communication is though a link from the patient
journal to the QR. One solution to this could be the tjänsterplattform. It will allow automatic
input of data from the EHRs to the DS DB. Today not all EHRs, could be able to transfer their
data automaticall to the DS DB.
Free text in the EHRs and freedom of input in the QR.
When doctors enter data in the EHR they are allowed to enter a lot of free text, that it is
difficult to get structured later. When it comes to the DS DB, there is also the problem that
there is not a specified set of indicators to be included, but the input in the QR, is only what
every doctor fills in. One proposal is to have a minimum of data to get entered in the DS DB, so
that the problem of null fields, is somehow more limited.
Legislation: Patient consent – Steering comittee
The patients should give their consent in order to send any data from the DS DB to the MS QR.
That does not happen for the Patient DB, where only the doctor decides, what will be sent and
what not.
Another important part is tha way that the data to be included in the MS QR is decided. There is
a committee that decides what is of interest to be icluded into the QR.
Standards followed
The MS QR DB is a simple mySQL DB. The only methodology that is followed is the ICD-10.
Other than this there is no other standarization followed, just free text and numbers. There are
no messaging standards, like HL7, but just standard SQL queries.
Entering PGHD to the QR
The problem with the entrance of PGHD to the QR, is that there should be a validation
mentioned above from the steering committee. This is probably the legal barier mentioned in
the interview. Also another factor to be taken into account, is where the PGHD are going to be
stored. One possible solution that was proposed, is the usage of an already existing DB, like
Hälsa för mig. The usage of the Patient DB is also possible, but there need to be done a
correlation of the patient that sends PGHD, with the DS DB, in order to have the identity of
each patient.
33
3.3 The proposed models Taking into account the data captured from the survey and the interviews, the study proposes a
set of models, which could be followed in order to have a feasible implementation.
As seen from interviews results, a solution for integrating PGHD in healthcare, should not go
through the EHR. This could by developing a new DB to host the PGHD, or by importing PGHD
directly to the patient DB. These 3 alternatives should be taken into account. There should be
an EHR-vendor independent solution, which will allow all MS patients across the country, to
send in their data in the same way.
3.3.1 The 3 proposed models
Before the study goes forward, the three proposed models are presented here.
Figure 8: Model 1 Data end up in the MS QR, through an intermediate cloud storage and tjänsteplattform
34
Figure 9: Model 2 Data end up in a DB parallel with MS QR DB, since they follow the same flow as before, but without being
validated from a doctor in Decision Support DB
Figure 10: Model 3: Data are entered directly in the Patient DB and end up in MS QR DB
35
On the smartphone there is authentication of the user with the usage of a solution like BankID,
which is commonly used in Sweden for verifying a person’s identity. For the upload of the data
through the internet, the same standards are proposed. They are the HL7 V2.6 for healthcare
information messaging, some IHE protocols and standards and other internet transfer protocols for
messaging over the web.
From the WD to the smartphone
The first step is the same for all models and is the communication of the WD with another
device that will receive and store the data. In our case this device will be a smartphone, while it
could well be a computer or a dedicated hub. An application that will cooperate with the WD,
will be used.
In order to have a minimum of interoperability, the proposal will use as a backbone the
protocols and standards that are used in Continua solution. The terminology which Continua
proposes to be used when it comes to numeric data, is SNOMED.
Data that come from applications like relapses or cognition, will be directly inputted in the
smartphone/tablet application by the user.
Figure 11: First step of the implementation
From the smartphone to the storage repository
The smartphone application will manage the synchronization, temporary storage and uploading
of the PGHD. In this part the standards that need to cooperate in order to transfer the PGHD
safely and correctly. Not only medical related standards will be used, but also internet transfer
and messaging protocols. The smartphone that acts as a gateway that uploads PGHD on the
web.
The messaging protocol that is proposed from Continua in this stage, is the HL7 V2.6. The
reason that HL7 V2.6 is used in favor of the more recent HL7 V3, is the reduction in bandwidth
36
that was observed with V2.6.(82) Other internet transfer protocols are followed too. There are
also some IHE guidelines used, in order to transform the transmited data according to the IHE2
Patient Care Device Technical Framework (IHE PCD TF). These IHE guidelines are based on the
HL7 V2.6 messaging and the ISO 11073 domain model for medical devices.(63)
In Model 1, the data are first sent into a cloud storage, or another storage repository and then
forwarded into the healthcare system.
Figure 12: Second step of the implementation - Model 1
2 IHE is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE
promotes the coordinated use of established standards such as DICOM and HL7 to address specific clinical needs in support of optimal patient
care. (From IHE web page)
37
In Model 3, the PGHD are directly fed into the Patient DB that stores all the electronic patient
forms data.
Figure 13: Second step of the implementation - Model 3
From the storage repository to the healthcare sector
In Model 1 the PGHD continue their flow through tjänsteplattform. This platform is a Swedish
initiative which acts as an integration engine and tries to interconnect the different structures
that exist in the Swedish healthcare system. Once data pass through this service, they are ready
to get shared with any service in the country that uses tjänsteplattform.
Here are two different versions. Model 1 feeds the data in Patient DB, while Model 2 sends the
data directly in a DB parallel with the MS QR DB, without passing a doctor’s approval.
38
Figure 14: Final step of the implementation - Model 1
Figure 15: Final step of the implementation - Model 2
39
Proposals for MS QR regarding the PGHD to get tracked
The PGHD that could be tracked, are the following:
Possible relapses Application
Cognition Application
Mobility/movement
problems
WD
Adherence to medication Sensor
Fatigue Application
Sleep disorders Sensor/WD
Stress Sensor
Weight tracking Sensor
Body temperature WD
3.4 Evaluation of the proposed models for the integration of patient generated
health data in MS Quality Register The evaluation of the proposed models was done with a semi-structured interview with 2
experts (Appendix 8). The models were evaluated based on their strengths and weaknesses.
Finally there was a blend of several features of the proposed models and a final suggestion
from the MS side was given. The model that was proposed, is feasible and can be implemented
in today’s reality.
There was also feedback regarding the PGHD that were proposed to be added in the MS QR and
their usage there. The QR side, posed the need for import of data that come also from self-
assessment mobile applications and not only wearable devices.
Figure 16: Schematic representation of feedback given about the models and PGHD proposed
40
Initially it was proposed that the gateways should not be restricted in the usage of a
smartphone, but also to consider the usage of other devices that can connect with Bluetooth
technology.
BankID was found a good approach in order to correctly certify the identity of the user. It adds
a security layer and also gives flexibility for the user in order to send his data from any device
using BankID.
It was commended that there should be a cloud solution in order to have the data stored there
temporarily, before they reach the final storage place In the QR.
The usage of standards for the transfer of the data to the cloud and from the cloud into the QR
gets simplified with the cloud solution. In case there was no clod solution, there should be
separate APIs for the transfer of data from Apple or Android devices to the QR and possibly
different approach in the manipulation of the data later. With the usage of the cloud, there is
one API that the devices will need to cooperate with and one API in order to push the data from
the cloud into the QR.
A lot of the WD vendors, use cloud storage for the data from their devices. Getting data from a
device that uses its own cloud storage solution, could help in order to have a connection with
the cloud of the vendor and take advantage of the already existing solution.
PGHD should be pushed from the cloud to the QR.
Some transformation of the data would be needed before they enter in the QR.
It was argued that the model should be based on today’s reality. Tjänsteplattform is still in an
initial stage and Hälsa for mig that was proposed as a storage solution, is still in a project phase.
Since it is unknown when these initiatives will be available for a full scale implementation, the
model cannot be based on them. The model though could be altered later, in order to adapt to
solutions like tjänsteplattform
The entry point for the import of PGHD in the MS QR flow, could be the Patient DB. Today there
are some data that are entered there, from external DBs, like statistical data for the patients
that finally died, or other set of data with some importance for the QR. Since this input of data
works today, it could also work for the input of the PGHD in the patient DB.
As for the final storage place of the data and whether they should end up in the MS QR or stay
in another DB, it was argued that this is not an answer that can be given today. One sure thing
is that the data cannot get transferred to MS QR DB immediately from the cloud.
The reason that there cannot be an answer on the DB that the data will be stored, is because
this answer is strongly connected with the ultimate goal of the usage of the data. This means
that it is different if the PGHD will be used in research or if they will only be used to produce
some graphs for example, about patient information.
All models have strong and weak points. Model 3 is the one that could be implemented today.
41
There was a lot of interest in solutions that can track cognitive and motoric ability of the
patients distantly. Applications for cognitive tests like SDMT, or fine motoric movements tests,
for the usage of the hands and picking ability, e.g. the 9 hole peg test. These tests were
mentioned to be of bigger interest. These measurements can only be done with the usage of
appropriate applications.
It would be of interest to be able to track relapses with reporting from patients. This kind of
tracking though, would enclose problems, since patient may mistake a simple worsening in
their state, as a relapse. Relapse reporting might not give objective from patients without the
prior medical assurance that a relapse really occurred.
There was also one proposal about correlating sleep disorders with fatigue.
There was critique about the usage of stress for monitoring the patient’s progression. The term
progression was found very vague and also we cannot be sure that a factor that causes stress is
really related with MS.
A final quite important comment was about the procedure that is done in order to have new
features added to the MS QR. There is a steering committee that has one monthly distant
conference –through phone or teleconference- and a physical conference annually, where
issues of the QR are discussed.
3.5 Evaluation of the proposed models according Design Science evaluation
criteria The evaluation criteria (Appendix 5) rate the 3 initial proposed models according to the answers
that were given from the participants in the focus group discussion.
Goal criteria: The criteria of efficacy, reliability and generality, are answered by model 3. It is
the one that can actually work today as is and it can possibly do it in a correct way. It is also
generalizable and can be used in any health system, since it does not follow any Sweden
specific solutions.
Environment criteria: There are 3 parts, about people, organization and technology. About the
people of the MS QR, the utility and understandability criteria, are answered by model 3, while
the ethicality issues are nonexistent for any of the models. About the consistency with the
organization, again model 3 is the one that fits the needs of MS QR in today’s reality. As for the
technology, Model 1 and 2 use the new technology of tjänsteplattform. There was no mention
for any side effect during the interview.
Structure: None of the three models can be considered complete, since after the evaluation a
new model was designed.
3.6 Proposing a feasible model for the implementation, after the re-design
according to the evaluation of MS QR
42
The final model that answers the aim of the study is the one below. It was created with the
usage of several aspects from the 3 initial models.
Figure 17: Implementation model after the evaluation with MS QR
43
4. DISCUSSION
The study has come up with a lot of interesting findings about the today’s reality regarding the
integration of PGHD in healthcare structures. In the following part there will be a presentation
of both the opportunities that exist, but also the challenges that need to be overcome, in order
to have a successful import of PGHD.
Opportunities that exist Challenges to be countered
Already existing technology for the flow of
data in the MS QR Patient DB from 3rd
sources
The final scope for the usage of the data
within MS QR
Pilots from companies in order to import
PGHD in the healthcare sector
Legislation issues to comply with
Simple and immediately implementable data
flow model, proposed from MS QR
Bureaucracy that can be time consuming
when it comes to innovation
Big variety of WDs and sensors that can cover
more and more healthcare issues
4.1 Challenges related with MS The initial thought for tracking relapses, would be the usage of an application where patient
would inform the physician that he is into a state of relapse. This solution though was almost
rejected, since there were concerns mentioned from the doctors’ side, as for the reliability of
the reporting. Lack of reliability from patients is a problem in this case.
As mentioned in a talk with a doctor about cognition, an application could be a way to track the
cognitive state of a patient. There are tests that can be used in a mobile application and can
actually measure the cognitive state of a patient. One reliable test like this, could be the SDMT.
Mobility problems are possible to be measured in several ways, either with WDs or with other
applications. Measurement of the actual activity of a patient in correlation with sleep patterns,
could give an image for the fatigue levels of a person. Fine motoric movements is another area
that can be tracked with more sophisticated applications.
The adherence to the medication could be a helpful measurement. There is an ISO certification
(ISO 11073-10472) for devices that are used for medication adherence monitoring.
Fatigue cannot be directly tracked, but there are several studies that show a strong correlation
between fatigue and sleep disorders. (17)(16) In some latest initiatives, Nintendo is trying to
measure fatigue, with the usage of sleep patterns.(83) These initiatives are yet in an early
stage.
Bladder and bowel problems, can be tracked with usage of a mobile application.
44
Sleep disorders can be easily and accurately measured with today’s WDs. As mentioned above,
it could be an indicator for the fatigue levels of a patient.
Stress can also be measured and presented it in a graphical way, but the interpretation of it
and/or the correlation with MS, is quite difficult. Stress can be triggered from many different
reasons and that makes it very difficult to have an unbiased interpretation of it. It could be a
good start to import it in a pilot stage and try to find correlations with long-term stress
measurements and MS state of the patient (e.g. relapses or worsening of the symptoms after a
big stress period, or a stabilization of MS symptoms during a low stress period).
Weight racking could be though an interesting input for the MS QR. According to the portal of
the QR(30), BMI is one of the measurements that the registry keeps track of. This feature could
be easily be imported to the QR with the usage of a smart scale.
One solution that could help in the tracking of several of the measurements that MS QR is
interested in, is an initiative from Google and Biogen in order to gather information of MS
patients. The ultimate goal of this project, is to correlate findings from different patients, in
order to find out why the progression of the disease is different amongst different
individuals.(84) The measurements are based in activity tracking and sleep patterns, but they
also use a tablet application in order to track cognitive state with the usage of the SDMT test.
There is also measurement of fine motoric movement, with the usage of an extra equipment
put on the screen of the tablet, which transforms the screen into a board and allows the patient
to perform the 9-hole peg test on the tablet. Finally there is also the possibility to use the tablet
to track the fine walking ability of the patient.
MS QR could get a lot of value out of PGHD. There are measurements that today are
unreachable for the medical personnel, or just reported voluntarily from the patient. With the
usage of PGHD there could be a lot more information to reach the healthcare system and
subsequently the QR.
Proposals for the QR:
Usage of a smartphone application to track MS patients’ cognition.
Tracking of patient mobility and sleep disorders and correlating it with the fatigue
forms that the patient is sending in the Patient DB at these dates.
Possible correlation of the appearance of relapses, in periods with sleeping problems or
reduced physical activities (and maybe stress).
Automatic measurement of patients’ BMI.
Tracking the adherence to medication.
The aforementioned proposals, could lead in some benefits for the MS QR since they could
provide:
Continuous flow of data, which will provide a standard set of parameters that will be
always captured and will not be dependent on which data doctors will copy from the
patient record into the QR journal.
45
Easiness for patients to commit tests of interest for the QR, like SDMT, without the need
to visit a healthcare facility.
4.2 About the evaluation of the models from MS QR There was not a clear proposal about where PGHD should be stored. This choice was absolutely
bond with the scope of the usage of the data. The most important part for the flow model is not
so much the technology that will be used or any other technical question, but how PGHD will be
used once they are retrieved from the patients.
Another interesting finding was that the proposal from MS QR regarding the data flow model,
was not using tjansteplattform. They were focused mainly on the existing solutions that would
make the implementation work right away.
Also, the usage of a cloud solution about the temporary storage of the data, can be a way to
import PGHD. Solutions like this seem to gain some market share, since Epic is using a similar
approach in order to import data from Apple HealthKit, into their EHR.
The proposed model from the QR, shows that at the moment there is no need for a
collaboration with an industry alliance like Continua in the terms of interoperability assurance.
Using a cloud and follow its specific APIs, is a feasible solution today. But, this could possibly be
a problem in the long-term. If a standardized way of communicating is used later, it is very
possible that it will follow a family of standards and Continua is one of the mostly used
nowadays. So even if the model works today, the non-compliance with a standard’s umbrella
may be proven a problem in later years.
Other details that should be clarified about the model
In order to have a sustainable model, we should take into account the way that the data are
sent into the healthcare sector. This has a series of questions, like:
In which time intervals should the data be captured from the patient (e.g. daily)
When should the data get forwarded to the healthcare structures (e.g. once a
week/daily)
Should the data be validated, or could they enter directly in a parallel DB with MS QR DB
In the models proposed there is also a note about the utilization of Health Innovation Platform
(HIP). HIP is an initiative that allows independent developers create solutions for healthcare, by
supporting them with APIs and other documentation. That can make it easier to create
healthcare applications that could be used in these models.
4.3 About cloud computing During the evaluation of the proposed flow models, the term cloud was used in a lot of the
cases. Since it was also promoted as a part of the final proposed model, it is important to delve
into the cloud capabilities and see how it could be used in the case of the MS QR.
46
According to National Institute of Standards and Technology, the definition of cloud computing
is: “Cloud computing is a model for enabling convenient, on-demand network access to a shared
pool of configurable computing resources (e.g. networks, servers, storage application and
services) that can be rapidly provisioned and released with minimal management effort or
service provider interaction”.
Five of the characteristics of a cloud are the following(85):
1. On-demand self-service: Computing capabilities provided to a customer according to the
requirement of the user and without human interaction.
2. Broad Network access: The cloud can be accessed by several clients, like tablets,
laptops, mobile phones and workstations.
3. Resource pooling: Computing resources are pooled to provide service to multiple
consumers. The computing resources can be present anywhere geographically and the
exact location of resources is not known to the user.
4. Rapid Elasticity: Depending on the user requirement, the capabilities and resources in
the cloud can be released and provided automatically.
5. Measured Service: The services provided to the user are measured by the cloud system
and are reported to the user and the provider. Based on the type of service, the cloud
system optimizes and controls the resource use by a metering capability.
Cloud architecture
There are 2 sections in a cloud, front and back end. The user receives the services from the
front end, while the cloud is in the back end. The two parts are connected through a network,
usually the internet. The figure below shows the cloud architecture:
Figure 18: Cloud computer architecture(85)
47
The three layers of the back end, are the following(86)(85):
1. Software as a service (SaaS): Applications, (eg, an EHR) are hosted by the cloud operator
and users access it. Examples: GoogleApps, Oracle on Demand, SalesForce.com, SQL
Azure5.
2. Platform as a service (PaaS): This is the middleware where web applications are built
and can be accessed through a web browser. With PaaS, developers can build web
applications without any tools installed on their computers. Examples: Force.com,
Google AppEngine, Windows Azure Platform, GoGrid Cloudcenter
3. Infrastructure as a service (IaaS): The equipment is outsourced, including storage
solutions, hardware needed, servers, etc. The service provider is the owner of the
equipment and is responsible for its operation and maintenance. Examples: Amazon
ECC, Eucalyptus, GoGrid, Flexiscale, Linode, RackSpace Cloud, Terremark
There are 4 different cloud types:
Public cloud: Cloud services are provided to the general public. Users rent virtual computers
and run their applications.
Private cloud: Cloud is operated for a specific organization.
Community cloud: Cloud is shared by several organizations with common concerns.
Hybrid cloud: It is a combination of 2 or more clouds (private, public, or community).
Figure 19: Different cloud models(86)
48
Challenges and opportunities of using cloud solutions in healthcare
When new technologies are used in healthcare there should always be a deep understanding of the
assets and the problems that may occur. Here is a list of the most important when it comes to using
clouds(86)(87):
Opportunities:
Cost-effective. Low cost in order to use cloud facilities
Fast implementation.
No need for changes in hospitals infrastructure
Flexibility in possible changes needed
Can be used from smaller hospitals with limited resources
Environmental friendly – Efficient use of resources
Accessible from several locations
Usage of the cloud solution of a wearable sensor vendor
Telemedicine possibilities
Utilization of big data possibilities
Challenges:
Users lack of trust in security and privacy of data
Loss of governance from the organization that uses the cloud for their needs
Uncertain cloud provider’s compliance
Data from Swedish patients must be stored in a cloud based in Sweden
Resource may be exhausted and cause unpredictable performance ups and downs
Challenge when a change of cloud provider may be used, with the danger of data lock-in
(difficult in transferring data to another cloud service provider)
Data transfer bottlenecks when uploading or downloading
Programming faults/bugs in large-scale distributed cloud systems
Security issues
Ownership of the data should be strictly clarified
Interoperability with healthcare standards
4.4 Challenges and opportunities of integration of PGHD in the Swedish reality
4.4.1 Tjänsteplattformen and Health Information Plattform
The structure of the Swedish healthcare system is built on a regional level. Each county has its
own healthcare structure and there is no national healthcare system. There are a lot of
localized solutions, which cannot communicate with the EHR of the neighboring county.
49
Sweden is trying to counteract this with its innovation. Initiatives like tjänsteplattform and
Health Innovation Platform (HIP) are two examples showing that there is an environment that
tries to find solutions for obstacles that would be a problem for the further improvement of
healthcare delivery.
Tjänsteplattform acts like an integration engine trying to interconnect all healthcare structures
and finally allow the seamless flow of patient data all across the country, no matter the vendor
of the health information. Both interviewees agree that the key to interoperability and
connection of the Swedish healthcare system is tjänsteplattform.
Figure 20: The way tjänsteplattform tries to alter Swedish healthcare structure (http://www.inera.se/TJANSTER--
PROJEKT/ICC-Integration-Competence-Center/)
This initiative is still in an early stage. Not many healthcare structures are using it and there are
issues to be taken into account, like which EHRs could actually cooperate with tjänsteplattform
and be able to exchange information through it automatically.
HIP on the other hand gives the opportunity to developers, to have access to APIs and open
data in order to create new innovative eHealth services for citizens. One of the advantages is
that these APIs comply with all the legal requirements that exist in Sweden. This can be a huge
asset that will allow the developer to focus mostly on the building of an application rather than
searching legal issues.
What we can see from both initiatives is that Sweden has an environment that allows and
promotes innovation. This can give a huge field for several initiatives in healthcare sector and
off course for the import of PGHD.
4.4.2 Law limitations
In order to have a wide and seamless usage of PGHD, there should be a clear legislative context,
which will define how the PGHD are protected and which is the way that they can be shared
amongst the healthcare system. That means till which extend has the patient a right to deny
the usage of his data or how the data will be stored, who will be able to have access to them,
etc.
50
In Sweden the personal information are strongly protected. Personuppgiftslagen (PUL),
translated as the Personal Data Act(88), gives a lot of rights to each individual regarding the
usage of his data.
One other aspect of Swedish legislation is that Swedish patient data, should be stored on
servers that are in the Swedish territory.
As for the MS QR we see that there are several differences in the way data are treated. The
data from Patient DB are forwarded to the DS DB, without the patient consent. As for the MS
QR BD, the patient though can opt-out and refuse to have his data used for the needs of the MS
QR.
There is a committee which has to agree on what new data will be included in the QR. Even if
there are not yet strong research proofs for the usage of a specific measurement for MS, there
could be at least a pilot that could allow PGHD to be tested and proven whether some of them
could be useful for the MS QR purposes.
4.5 Generalization The scope of the study, is to give a solution on the specific problem of importing PGHD, in the
MS QR. The import of PGHD in healthcare though, is something more general. Sweden is an
innovative country and sooner or later will start to use PGHD on a regular basis. The pilots that
already exist and also the facilitation from the Swedish state, with the launching of HIP and
tjänsteplattform, assist the shift in the Swedish healthcare system.
This study could be generalized for the needs of another QR maybe, or for the needs of an EHR.
The findings about the law limitations that exist, are the same for all across Sweden, not only
for the narrow environment of MS QR. Also the existence of tjansteplattform, even if not used
in the data flow model for MS QR, is a sign that the interoperability across the country is
approaching and bigger, nationwide projects, could be initiated in the future.
The proposal from the MS QR, about the usage of a simple model, that not follows any Swedish
special platform, shows that this model could be followed in other countries too. This solution
follows the mentality that companies like Apple, Google or Microsoft, want to give in the new
area of PGHD. Apple Healthkit is promoting exactly this model for data acquisition.
4.6 Future research This study can be a first step towards the scientific approach of integrating PGHD in Swedish MS
QR. It is mostly a feasibility study which proves that the implementation is actually possible, in
technical terms. There is the need though for more elaboration on the reasons for which the
MS QR will use the data.
The development and evaluation of mobile applications that will import patient data from tests,
like the SDMT, is a really important next step in order to get PGHD of interest for the QR.
51
A later study could focus mostly on the mapping of the chances of the usage of PGHD in the
environment of MS QR.
Another option could be the technical trial of the proposed model in order to have a proof of
concept that the model is functional in real circumstances.
A choice that could be implemented after some time, can check the new needs, challenges or
opportunities, which could be possibly born with the full scale utilization of solutions like
tjanstepltform.
Also, a study on whether the findings of this work could be followed in other healthcare
structures in Sweden could be done.
4.7 Limitations The study was made between February and May 2015. There were a lot of different parameters
to be explored before the start of the study, that means:
Wearable devices
Multiple Sclerosis and factors that affect it
Cases where WDs were used for MS management
Initiatives relative to PGHD integration
Technical challenges and the reality that exists today with standards and protocols
The reality in the Swedish Multiple Sclerosis Registry
The main challenge for the study, was that the researcher was familiar neither with the field of
MS nor with the field of WDs. Everything was explored after the start of the thesis in February.
This gave a lot of experience and new knowledge. The time constraints did not allow to have a
more specific model technically, since it was difficult to get in contact with people from Inera,
the company that runs tjänsteplattform. All information for Inera, were taken from web
sources.
Another limitation of the study is the fact that patients did not take part in any point of the
study. This was done, since the study focused mostly on the technical side of the
implementation.
52
5. CONCLUSION
The study has come up with many interesting findings regarding the integration of PGHD in the
MS QR.
The technology for the integration of PGHD in the MS QR exists. Even without the usage of
Swedish innovations like tjänsteplattform or other interoperability solutions like Continua, this
integration is possible today. It would be better though, that the implementation will follow the
Swedish strategy in terms of standards and tools used. Otherwise in a later time when some
official guidelines appear, the MS QR model will have to adapt to the new reality.
The biggest issue though to get answered is not how the integration will be done, but what MS
QR wants to achieve with the patient data. The flow model is strongly related with the way that
the data will be utilized, so until this answer is given, the final flow model will be a question.
Another important finding, was that the most important measurements, will actually come
from the usage of applications and not data from WDs. MS is a disease that has a lot of
variables that are measurable only by questionnaires or tests. Thus it was found that WDs are
not the way to have a full monitoring of a MS patient, but mobile applications would also be
needed.
Also the legal context and rest regulatory aspects regarding the usage of PGHD must be
clarified.
Finally, the Swedish state should give the technical guidelines in terms of standards/protocols
used so that all initiatives taken today can follow the same rules.
53
6. REFERENCES:
1. Shapiro M, Johnston D, Wald J, Mon D. Patient-Generated Health Data - White Paper [Internet]. Durham; 2012. Available from: http://www.healthit.gov/sites/default/files/rti_pghd_whitepaper_april_2012.pdf
2. Patient-Generated Health Data Fact Sheet [Internet]. National Learning Concortium; 2014. p. 2. Available from: http://www.healthit.gov/sites/default/files/patient_generated_data_factsheet.pdf
3. Sands DZ, Wald JS. Transforming health care delivery through consumer engagement, health data transparency, and patient-generated health information. Yearb Med Inform [Internet]. 2014;9:170–6. Available from: http://www.ncbi.nlm.nih.gov/pubmed/25123739
4. Alemdar H, Ersoy C. Wireless sensor networks for healthcare: A survey. Comput Networks [Internet]. Elsevier B.V.; 2010;54(15):2688–710. Available from: http://dx.doi.org/10.1016/j.comnet.2010.05.003
5. Diseases and Conditions - Multiple sclerosis [Internet]. Mayo Clinic. [cited 2015 Feb 3]. Available from: http://www.mayoclinic.org/diseases-conditions/multiple-sclerosis/basics/definition/con-20026689
6. Robinson I, Warren KG. Multiple Sclerosis [Elektronisk resurs]. 1988.
7. Birnbaum G. Multiple Sclerosis. Cary, NC, USA: Oxford University Press, USA; 2009. 157 p.
8. The 4 Types of MS The Importance of Early Treatment How Is MS Treated? [Internet]. [cited 2015 Feb 25]. Available from: http://www.multiplesclerosis.com/us/treatment.php
9. Rabins P V, Brooks BR, O’Donnell P, Pearlson GD, Moberg P, Jubelt B, et al. Structural brain correlates of emotional disorder in multiple sclerosis. Brain. 1986;109 ( Pt 4:585–97.
10. Mohr DC, Hart SL, Julian L, Cox D, Pelletier D. Association between stressful life events and exacerbation in multiple sclerosis: a meta-analysis. BMJ. 2004;328(March):731.
11. Burns MN, Nawacki E, Kwasny MJ, Pelletier D, Mohr DC. Do positive or negative stressful events predict the development of new brain lesions in people with multiple sclerosis? Psychol Med. 2014;44:349–59.
54
12. Mohr DC, Lovera J, Brown T, Cohen B, Neylan T, Henry R, et al. A randomized trial of stress management for the prevention of new brain lesions in MS. Neurology. 2012;79:412–9.
13. Artemiadis AK, Vervainioti A a, Alexopoulos EC, Rombos A, Anagnostouli MC, Darviri C. Stress Management and Multiple Sclerosis: A Randomized Controlled Trial. J Natl Acad Neuropsychol [Internet]. 2012;27(April):406–16. Available from: http://www.ncbi.nlm.nih.gov/pubmed/22491729
14. Brass SD, Duquette P, Proulx-Therrien J, Auerbach S. Sleep disorders in patients with multiple sclerosis. Sleep Med Rev [Internet]. Elsevier Ltd; 2010;14(2):121–9. Available from: http://dx.doi.org/10.1016/j.smrv.2009.07.005
15. Merlino G, Fratticci L, Lenchig C, Valente M, Cargnelutti D, Picello M, et al. Prevalence of “poor sleep” among patients with multiple sclerosis: An independent predictor of mental and physical status. Sleep Med [Internet]. Elsevier B.V.; 2009;10(1):26–34. Available from: http://dx.doi.org/10.1016/j.sleep.2007.11.004
16. Attarian HP, Brown KM, Duntley SP, Carter JD, Cross AH. The relationship of sleep disturbances and fatigue in multiple sclerosis. Arch Neurol. 2004;61:525–8.
17. Kaminska M, Kimoff RJ, Schwartzman K, Trojan D a. Sleep disorders and fatigue in multiple sclerosis: Evidence for association and interaction. J Neurol Sci [Internet]. Elsevier B.V.; 2011;302(1-2):7–13. Available from: http://dx.doi.org/10.1016/j.jns.2010.12.008
18. Krupp LB, LaRocca NG, Muir-Nash J, Steinberg a D. The fatigue severity scale. Application to patients with multiple sclerosis and systemic lupus erythematosus. Arch Neurol. 1989;46:1121–3.
19. Shammas L, Zentek T, von Haaren B, Schlesinger S, Hey S, Rashid A. Home-based system for physical activity monitoring in patients with multiple sclerosis (Pilot study). Biomed Eng Online [Internet]. 2014;13:10. Available from: http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=3927216&tool=pmcentrez&rendertype=abstract
20. Weikert M, Motl RW, Suh Y, McAuley E, Wynn D. Accelerometry in persons with multiple sclerosis: Measurement of physical activity or walking mobility? J Neurol Sci [Internet]. Elsevier B.V.; 2010;290(1-2):6–11. Available from: http://dx.doi.org/10.1016/j.jns.2009.12.021
21. Motl RW, Pilutti L a., Learmonth YC, Goldman MD, Brown T. Clinical Importance of Steps Taken per Day among Persons with Multiple Sclerosis. PLoS One [Internet]. 2013;8(9). Available from: http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0073247
55
22. Alaqtash M, Yu H, Brower R, Abdelgawad A, Sarkodie-Gyan T. Application of wearable sensors for human gait analysis using fuzzy computational algorithm. Eng Appl Artif Intell [Internet]. Elsevier; 2011;24(6):1018–25. Available from: http://dx.doi.org/10.1016/j.engappai.2011.04.010
23. Spain RI, St. George RJ, Salarian a., Mancini M, Wagner JM, Horak FB, et al. Body-worn motion sensors detect balance and gait deficits in people with multiple sclerosis who have normal walking speed. Gait Posture [Internet]. Elsevier B.V.; 2012;35(4):573–8. Available from: http://dx.doi.org/10.1016/j.gaitpost.2011.11.026
24. Spain RI, Mancini M, Horak FB, Bourdette D. Body-worn sensors capture variability, but not decline, of gait and balance measures in multiple sclerosis over 18 months. Gait Posture [Internet]. Elsevier B.V.; 2014;39(3):958–64. Available from: http://dx.doi.org/10.1016/j.gaitpost.2013.12.010
25. Dennison L, Moss-Morris R, Chalder T. A review of psychological correlates of adjustment in patients with multiple sclerosis. Clin Psychol Rev [Internet]. Elsevier Ltd; 2009;29(2):141–53. Available from: http://dx.doi.org/10.1016/j.cpr.2008.12.001
26. Sá MJ. Psychological aspects of multiple sclerosis. Clin Neurol Neurosurg. 2008;110:868–77.
27. Nationella Kvalitetsregister [Internet]. [cited 2015 Apr 1]. Available from: http://www.kvalitetsregister.se/
28. Emilsson L, Lindahl B, Köster M, Lambe M, Ludvigsson JF. Review of 103 Swedish Healthcare Quality Registries. J Intern Med [Internet]. 2015;277(1):94–136. Available from: http://ki.se/sites/default/files/ludvigsson_journal_of_internal_medicine.pdf
29. Swedish Neuroscience Register [Internet]. [cited 2015 Feb 3]. Available from: http://www.socialstyrelsen.se/register/registerservice/nationellakvalitetsregister/svenskaneuroregistret
30. Multipel skleros [Internet]. Svenska Neuroregister. [cited 2015 Apr 1]. Available from: http://www.neuroreg.se/sv.html/multipel-skleros
31. Ninety Million Wearable Computing Devices Will Be Shipped in 2014 Driven by Sports, Health and Fitness [Internet]. ABI research. 2014 [cited 2015 Feb 2]. Available from: https://www.abiresearch.com/press/ninety-million-wearable-computing-devices-will-be-
32. Wearable Technology and Wearable Devices Everything You Need to Know [Internet]. 2014 [cited 2015 Feb 10]. Available from: http://www.wearabledevices.com/what-is-a-wearable-device/
56
33. WEARABLE TECH MARKET [Internet]. 2015 [cited 2015 Feb 10]. Available from: http://vandrico.com/database
34. Apple Watch [Internet]. [cited 2015 Feb 12]. Available from: https://www.apple.com/se/watch/
35. Google Glass [Internet]. [cited 2015 Feb 12]. Available from: http://www.google.com/glass/start/
36. Nike Fuelband [Internet]. [cited 2015 Feb 12]. Available from: http://fuelbandsverige.se/
37. Wearable Tech Discover the GearTM that works best for your life. [Internet]. [cited 2015 Feb 12]. Available from: http://www.samsung.com/us/mobile/wearable-tech
38. Chen I-M, Phee SJ, Luo Z, Lim CK. Personalized biomedical devices & systems for healthcare applications. Front Mech Eng China. 2010;6(1):3–12.
39. Wood WA, Bennett A V, Basch E. Emerging uses of patient generated health data in clinical research. Mol Oncol [Internet]. Elsevier B.V; 2014;4–10. Available from: http://dx.doi.org/10.1016/j.molonc.2014.08.006
40. Chan M, Estève D, Fourniols J-Y, Escriba C, Campo E. Smart wearable systems: Current status and future challenges. Artif Intell Med [Internet]. Elsevier B.V.; 2012;56(3):137–56. Available from: http://dx.doi.org/10.1016/j.artmed.2012.09.003
41. Cleland JGF, Louis A a., Rigby AS, Janssens U, Balk AHMM. Noninvasive home telemonitoring for patients with heart failure at high risk of recurrent admission and death: The Trans-European Network-Home-Care Management System (TEN-HMS) study. J Am Coll Cardiol. 2005;45(10):1654–64.
42. Scalvini S, Zanelli E, Volterrani M, Martinelli G, Baratti D, Buscaya O, et al. A pilot study of nurse-led, home-based telecardiology for patients with chronic heart failure. J Telemed Telecare. 2004;10(April 2000):113–7.
43. Goldberg LR, Piette JD, Walsh MN, Frank T a., Jaski BE, Smith AL, et al. Randomized trial of a daily electronic home monitoring system in patients with advanced heart failure: The Weight Monitoring in Heart Failure (WHARF) trial. Am Heart J. 2003;146(03):705–12.
44. Orwat C, Graefe A, Faulwasser T. Towards pervasive computing in health care - a literature review. BMC Med Inform Decis Mak. 2008;8:26.
45. Schwiebert L, Gupta SKS, Weinmann J. Research challenges in wireless networks of biomedical sensors. Proc 7th Annu Int Conf Mob Comput Netw - MobiCom ’01 [Internet]. 2001;9:151–65. Available from:
57
http://dl.acm.org/citation.cfm?id=381692\nhttp://portal.acm.org/citation.cfm?doid=381677.381692
46. Tognetti A, Lorussi F, Bartalesi R, Quaglini S, Tesconi M, Zupone G, et al. Wearable kinesthetic system for capturing and classifying upper limb gesture in post-stroke rehabilitation. 2005;16:1–16.
47. Rodriguez-Martin D, Samà A, Perez-Lopez C, Català A, Cabestany J, Rodriguez-Molinero A. SVM-based posture identification with a single waist-located triaxial accelerometer. Expert Syst Appl [Internet]. Elsevier Ltd; 2013;40(18):7203–11. Available from: http://dx.doi.org/10.1016/j.eswa.2013.07.028
48. Abdul Razak AH, Zayegh A, Begg RK, Wahab Y. Foot plantar pressure measurement system: A review. Sensors (Switzerland). 2012;12:9884–912.
49. Saito M, Nakajima K, Takano C, Ohta Y, Sugimoto C, Ezoe R, et al. An in-shoe device to measure plantar pressure during daily human activity. Med Eng Phys [Internet]. Institute of Physics and Engineering in Medicine; 2011;33(5):638–45. Available from: http://dx.doi.org/10.1016/j.medengphy.2011.01.001
50. Mariani B, Jiménez MC, Vingerhoets FJG, Aminian K. On-shoe wearable sensors for gait and turning assessment of patients with parkinson’s disease. IEEE Trans Biomed Eng. 2013;60(1):155–8.
51. Xu W, Liu JJ. Smart Insole : A Wearable System for Gait Analysis. Proc 5th Int Conf Pervasive Technol Relat to Assist Environ. 2012;1–4.
52. Ding D, Cooper R a., Pasquina PF, Fici-Pasquina L. Sensor technology for smart homes. Maturitas [Internet]. Elsevier Ireland Ltd; 2011;69(2):131–6. Available from: http://dx.doi.org/10.1016/j.maturitas.2011.03.016
53. Van Wouwe NC, Valk PJL, Veenstra B. Sleep monitoring: A comparison between three wearable instruments. Int J Psychophysiol. 2010;77(July):288–9.
54. Bianchi AM, Mendez MO, Cerutti S. Processing of signals recorded through smart devices: Sleep-quality assessment. IEEE Trans Inf Technol Biomed. 2010;14(3):741–7.
55. Choi S, Jiang Z. A wearable cardiorespiratory sensor system for analyzing the sleep condition. Expert Syst Appl. 2008;35:317–29.
56. Kayyali H a, Weimer S, Frederick C, Martin C, Basa D, Juguilon J a. Remotely Attended Home Monitoring of Sleep Disorders. 2008;14(4):371–4.
57. Howie L, Hirsch B, Locklear T, Abernethy AP. Assessing the value of patient-generated data to comparative effectiveness research. Health Aff. 2014;33:1220–8.
58
58. Apple Research Kit [Internet]. [cited 2015 Mar 10]. Available from: https://www.apple.com/researchkit/
59. Marquard JL, Garber L, Saver B, Amster B, Kelleher M, Preusse P. Overcoming challenges integrating patient-generated data into the clinical EHR: Lessons from the CONtrolling Disease Using Inexpensive IT - Hypertension in Diabetes (CONDUIT-HID) Project. Int J Med Inform [Internet]. Elsevier Ireland Ltd; 2013;82(10):903–10. Available from: http://dx.doi.org/10.1016/j.ijmedinf.2013.04.009
60. HealthVault [Internet]. [cited 2015 Feb 15]. Available from: https://www.healthvault.com/se/en
61. Health. An entirely new way to use your health and fitness information. [Internet]. [cited 2015 Feb 14]. Available from: https://www.apple.com/ios/whats-new/health/
62. Diamond D. iPhone 6: Leaked Details About Apple’s HealthKit Rollout [Internet]. 2014 [cited 2015 Feb 14]. Available from: http://www.forbes.com/sites/dandiamond/2014/08/12/iphone-6-leaked-details-about-apples-healthkit-rollout/
63. Sujansky W, Kunz D. A standard-based model for the sharing of patient-generated health information with electronic health records. Pers Ubiquitous Comput [Internet]. 2014;9–25. Available from: http://www.projecthealthdesign.org/media/file/Standard-Model-For-Collecting-And-Reporting-PGHI_Sujansky_Assoc_2013-07-18.pdf
64. ISO/IEEE 11073-30400:2012(en) [Internet]. 2012 [cited 2015 Mar 3]. Available from: https://www.iso.org/obp/ui/#iso:std:iso-ieee:11073:-30400:ed-1:v1:en
65. Health Device Profile The Bluetooth® SIG Health Device Profile (HDP) [Internet]. [cited 2015 Mar 4]. Available from: https://www.bluetooth.org/en-us/specification/assigned-numbers/health-device-profile
66. ZigBee PRO with Green Power [Internet]. [cited 2015 Mar 4]. Available from: http://www.zigbee.org/zigbee-for-developers/network-specifications/zigbeepro/
67. Telia Healthcare - ger mer vård för pengarna [Internet]. 2014 [cited 2015 Mar 5]. Available from: http://www.telia.se/media/showArticleView?id=9effef8d-c8ff-458b-884c-b4654c5a5190
68. SNOMED-CT [Internet]. [cited 2015 Mar 5]. Available from: http://ihtsdo.org/snomed-ct/
69. International Classification of Diseases (ICD) [Internet]. 2015 [cited 2015 Mar 5]. Available from: http://www.who.int/classifications/icd/en/
59
70. ISO 13606-5:2010(en) [Internet]. [cited 2015 Mar 9]. Available from: https://www.iso.org/obp/ui/#iso:std:iso:13606:-5:ed-1:v1:en
71. Yuksel M, Dogac A. Interoperability of medical device information and the clinical applications: An HL7 RMIM based on the ISO/IEEE 11073 DIM. IEEE Trans Inf Technol Biomed. 2011;15(4):557–66.
72. Martınez I, Escayola J, Martınez-Espronceda M, Munoz P, Daniel Trigo J, Munoz A, et al. Seamless Integration of ISO/IEEE11073 Personal Health Devices and ISO/EN13606 Electronic Health Records into an End-to-End Interoperable Solution. Telemed e-Health [Internet]. 2010;16(10):993–1004. Available from: http://diec.unizar.es/~imr/personal/docs/paper10JMT.pdf
73. Trigo JD, Kohl CD, Eguzkiza A, Martínez-Espronceda M, Álesanco A, Serrano L, et al. On the seamless, Harmonized use of iso/ieee11073 and Openehr. IEEE J Biomed Heal Informatics. 2014;18(3):872–84.
74. Khan WA, Hussain M, Afzal M, Amin MB, Lee S. Healthcare standards based sensory data exchange for Home Healthcare Monitoring System. Proc Annu Int Conf IEEE Eng Med Biol Soc EMBS. 2012;1274–7.
75. Hevner a. R, March ST, Park J. Design Science in Information Systems Research. MIS Q [Internet]. 2004;28(1):75–105. Available from: http://dl.acm.org/citation.cfm?id=2017217
76. Hevner AR. A Three Cycle View of Design Science Research A Three Cycle View of Design Science Research. 2007;19(2):87–92. Available from: http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1017&context=sjis
77. Iivari J. A Paradigmatic Analysis of Information Systems As a Design Science A Paradigmatic Analysis of Information Systems As a Design Science. Scandanavian J Inf Syst [Internet]. 2007;19(2):5. Available from: http://heim.ifi.uio.no/~petterog/Kurs/Design Science/DR_IIV.pdf
78. Håkansson A. Portal of Research Methods and Methodologies for Research Projects and Degree Projects. Int Conf Front Educ Comput Sci Comput Eng [Internet]. 2013;13:67–73. Available from: http://worldcomp-proceedings.com/proc/p2013/FEC2979.pdf
79. Denscombe M. The good research guide [Elektronisk resurs] : for small-scale social research projects. 4th ed. Maidenhead: Open University Press; 2010.
80. Anderson R. Thematic Content Analysis (TCA) Descriptive Presentation of Qualitative Data. Online [Internet]. 2007;15:1–4. Available from: http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:Thematic+Content+Analysis+(TCA).+Descriptive+Presentation+of+Qualitative+Data#0
60
81. Prat N, Comyn-wattiau I, Cnam C. ARTIFACT EVALUATION IN INFORMATION SYSTEMS DESIGN-SCIENCE RESEARCH – A HOLISTIC VIEW.
82. Continua Health Alliance. H . 810 Interoperability design guidelines for personal health systems. 2014;(Cdg):402.
83. Knight S. Nintendo to develop “quality of life” device to track sleep, fatigue: CEO [Internet]. Reuters. 2014 [cited 2015 Apr 29]. Available from: http://www.reuters.com/article/2014/10/30/us-nintendo-products-idUSKBN0IJ04J20141030
84. Pai A. Google, Biogen will use wearable sensors to study multiple sclerosis [Internet]. MobiHealthNews. 2015 [cited 2015 Apr 29]. Available from: http://mobihealthnews.com/40031/google-biogen-will-use-wearable-sensors-to-study-multiple-sclerosis/
85. Rani BK, Rani BP, Babu a. V. Cloud Computing and Inter-Clouds – Types, Topologies and Research Issues. Procedia Comput Sci [Internet]. Elsevier Masson SAS; 2015;50:24–9. Available from: http://linkinghub.elsevier.com/retrieve/pii/S1877050915005074
86. Kuo AM-H. Opportunities and Challenges of Cloud Computing to Improve Health Care Services [Internet]. School of Health Information Science, University of Victoria, Victoria, BC, Canada. 2011 [cited 2015 May 28]. Available from: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3222190/
87. Cloud Standards Customer Council. Impact of Cloud Computing on Healthcare. 2012;(November).
88. Personuppgiftslagen [Internet]. [cited 2015 May 5]. Available from: http://www.datainspektionen.se/lagar-och-regler/personuppgiftslagen/
61
APPENDICES
Appendix 1 Device specialization standards, under ISO/IEEE 11073:
11073-10404 Device specialization Pulse Oximeter
11073-10407 Device specialization Blood Pressure Monitor
11073-10408 Device specialization Thermometer
11073-10415 Device specialization Weighing Scale
11073-10417 Device specialization Glucose Meter
11073-10418 Device specialization International Normalized Ratio (INR) monitor
11073-10419 Device specialization Insulin pump
11073-10420 Device specialization Body composition analyzer
11073-10421 Device specialization Peak flow
11073-10424 Device specialization Sleep Apnea Breathing Therapy Equipment (SABTE)
11073-10425 Device specialization Continuous Glucose Monitor (CGM)
11073-10441 Device specialization Cardiovascular fitness and activity monitor
11073-10442 Device specialization Strength fitness equipment
11073-10471 Device specialization Independent living activity hub
11073-10472 Device specialization Medication monitor
62
Appendix 2
The survey
63
64
65
66
Appendix 3
Interview with Carmona – The Company managing the MS QR DB
1. How are the data entered in MS QR today (manual/automatic)? Is there any level of
communication between existing EHRs and the MS QR?
If automatic processes exist for importing data, where do these data come from (e.g.
EHRs, patient portals, lab exams)?
What kind of data are automatically entered (e.g. blood exams)?
In case of manual entrance of data into the QR, is there any protocol that is used from
people that do this job? How many are these people and do they get any training?
2. How do you prevent the purity of the data entered in the MS QR? Are the data that end up
into the MS QR DB, somehow validated?
If yes, who is the person that does this job?
If not medical personnel, which people and how are they trained to do this validation?
3. Is there any kind of device used when importing the data into the MS QR (e.g. electronic
blood pressure measurement)?
4. What kind of raw data are stored in the QR today (e.g. blood pressure, heart rate)?
5. Do you think that PGHD should be sent directly into the MS QR, or go through an
intermediary data storage (e.g. a server built just for this reason)?
In case of an intermediate data storage, should PGHD be stored there permanently, or
get also forwarded and stored in the MS QR?
6. Could you describe a data flow that you think would be the most suitable, regarding the
way PGHD should be transferred into the MS QR?
7. From your experience do you think that the MS QR is in need of more data or more quality
data?
8. Is the DB of the QR custom made, or it is the same with other DBs used in other
QRs/organizations?
9. What kind of standards (if any) are used from the MS QR, regarding the storage of the data
(e.g. HL7, OpenEHR) and the terminology (ICD-10, SNOMED-CT, LOINC)?
67
10. In case a set of new entries is needed to be created in order to store the RAW data from the
WDs, how easy is this and what challenges would arise? Is there a certain procedure you
should follow?
11. Is there an established communication channel between any of the EHRs used across
Sweden and MS QR?
If yes, what standards are involved and how do you achieve interoperability?
12. Are you aware of the tjänster platform and the capabilities it has for interconnecting
healthcare data structures with external systems?
If yes, do you think MS QR could be able to connect to this?
68
Appendix 4
Interview with a company implementing a pilot for WDs PGHD import in healthcare sector.
1. Can you give me an image of what you company’s solution is?
2. Is there any existing initiative for home monitoring used today, in any form?
3. What is the data flow that PGHD follows in order to end up in a healthcare DB?
4. Who owns the data that your company stores?
5. Do you use push or pull methods for communicating the PGHD?
6. What are the criteria in order to use a Wearable Device in your company’s platform?
7. What kind of Patient Generated Health Data (PGHD) can your company track?
8. Who do you collaborate with?
9. How is the communication between your company and the Healthcare system achieved?
10. What kind of standards are you using?
69
Appendix 5 Artifact evaluation criteria
Goal
Efficacy Validity/Reliability Generality
Efficacy: the degree to which the artifact achieves its goal
Validity/reliability: the degree to which the artifact works correctly
Generality: the goal generality, the broader the goal addressed by the artifact, the more general
the artifact
Environment
Consistency with people
Utility Understandability Ethicality Side-effects
Utility: measures the quality of the artifact in practical use.
Consistency with organization
Fit with organization Side effects
Fit with organization: The alignment of the artifact with MS QR environment.
Consistency with technology
Harnessing of recent technologies Side effects
Harnessing of recent technologies: Whether new technology is used in the artifact
70
Structure
Completeness Simplicity
Evolution
Robustness/Evolution
Robustness/Evolution: The ability to respond to the fluctuations of the environment.
Please provide any feedback you think about the model.
Is any of the models feasible?
Could any of them be used for the MS QR?
What should be changed/adjusted?
71
Appendix 6
Possible relapses
Average: 8.34
Cognition
Average: 8.34
72
Mobility/movement problems
Average: 8.29
Adherence to medication
Average: 8.23
73
Fatigue
Average: 8.06
Bladder/bowel problems
Average: 7.51
74
Infections
Average: 7.20
Sleep disorders
Average: 6.74
75
Stress
Average: 6.37
Weight tracking
Average: 5.46
76
Body temperature
Average: 3.54
77
Appendix 7
Interviews transcribed text
Sensors to be used and interoperability with them
“We don’t know today what sensors will be launched in a week’s time. There will be loads and
loads of different sources out there. So we need to find an open standard, some open standards,
that allows us to communicate all these sensors.”
“That is the main reason for our platform. Gather information regardless of what sensors, store
the information and then send it over have it integrated into the healthcare provider”.
“[…] counties will need to find certain standards that are pointing and say, this is a good
communication protocol and those sensors they are following these standards. So we have been
looking around and we have found one standard that has been applied around, called Continua”
“[…] we are using Continua. I don’t think that Continua will be able to cover all our needs. There
will be probably other standards needed as well.”
Connection with healthcare sector / what is needed from the healthcare sector in order to fix
a path for the transfer of PGHD in healthcare DBs?
“In order that different regions cooperate, Inera have set up a service called tjänsteplattform,
which is basically an integration engine. And in that engine there are a lot of contracts on how
you exchange data with different providers. So we are now building a certain contract, stating
that tjänsteplattform, will go into our cloud and pick out certain data that is needed for the
hospital. Our cloud will be connected to tjänsteplattform and we will have rules there, what kind
of data should be transferred. So we are cooperating with Inera to set up those rules, […] and all
the other healthcare regions that are also connected to that platform, they don’t need to invest
in anything new, they don’t need to build any new integration. They just need to state that we
want to use this integration engine to pick up that medical information for a specific patient.”
“[…] since we are doing this pilot now, we can go to Uppsala and say, you are connected already
to tjänsteplattform and you have been trying this with your heart medication department,
tomorrow you may want to do it with your gastro, or with your MS and do it with the same
platform. […] So they will put pressure on the provider of the health record. So they will go to
e.g. Cambio and say, you need to help us integrate with it. We think that all around Sweden the
health regions will do the same. They will demand from the provider of their medical records
that they integrate with this solution. Because this will simplify life for them a lot”.
78
“We are mapping the data into our application. So if there is for instance a scale and that
certain scale is also used in a hospital, we know which are the certain amount of data that we
need to gather from that scale and we need to map it into our application”.
Legislation
“[…] we need to have an agreement between our company and each individual patient, that
they allow our company to store their data. After we have been gathering the data by the
smartphone app, they are sent through the internet to a cloud and the cloud in this case is our
company’s servers in Stockholm”.
“[…] we are storing it locally in Sweden, according to Swedish law and there is a certain law
called Personuppgiftslagen (PUL). So we tell the customer or the patients that we are going to
store this sensitive data for you, according to PUL. We can never do anything with your data, we
are not allowed to run these data and try to find any kind of information. The only thing that we
do, is that we store it for you on your personal account. It is your personal data and you own it.
We are not allowed to do anything with it.”
The way that data are forwarded to the healthcare sector in today’s pilots
“[…] is a set of rules, that you can use and say that, I want my data to be transferred to the
hospital once per week, or I want it to be sent with this frequency. You can set up a lot of
different rules on how these data should be transferred”
“[…] the doctor will help them (the patients) and say that we probably need your data in those
intervals. But practically, it’s up to the patient to decide that.”
“You will not allow one patient to say I want it to be sent every hour. It is up to the doctor to
inform them. In principal, it is their data account and they cannot be forced.”
“[…] the patient needs to give an allowance that they give their data information. This is
something they need to approve. But then the healthcare provider, they also need to use a pull
function otherwise they will be overloaded with data and maybe data they don’t even want. So
they need also to approve, that we approve that patients’ data is entering to our system. So
there is a push from the patient and a pull from the healthcare provider side, in order for this to
work”.
How the data are entered today in the MS QR
79
“[…] there is a transport of data, export of data from the DS DB to the QR only for those
patients that have said yes to be available in the QR. But they do not have to say yes to be part
of the decision support anyways because that's more of a journal system”
“[…] there is a third DB, which is the patient DB, which is the one that the patient meets, or the
patient application which is the proms the web forms that the patient fills in. So the patient fills
in the web forms, the doctor opens up when he meets the patient, looks if there are any forms
registered by this patient and then he can choose to import it to the DS DB. So it is pretty
different. And the reason for this is that the patient is not allowed to enter data directly into the
DS DB. So there are certain lines here, legal lines between these DBs”.
“There is anonymized data in the patient DB. No personal ID no social security number”
“[…] the patient actually needs to be part of the DS DB to be able to enter data to the patient
DB”
“Patient DB can include a lot of different patient cases”
“Patients fill in web forms, after they login to this application”
“The flow (of data) is more or less like this, one direction. There is no backflow”
“It is diagnosis data, course information, treatment, visits. MRIS, CSFs. Everything related to the
patient and the visit at the doctor. There are off course some of these validated forms, like the
MSIS 29. They end up in the QR as well”
Challenges about transfering data from the EHR and DS DB to the MS QR
Technical
“There is only one communication with the EHR and it is not concerned to data transfer at all.
You can just go into the EHR and then do a jump on a certain patient to the DS system. But all
the data are entered manually in the DS”
“the doctor has to enter data two times”
“This has been a problem for several years that there is no data transfer”
“the national service platform (tjansterplattform), will be the key for this. The QR could
communicate with the journal system or the EHR, though the tjanteplattform”
“probably during this year, it’s going to be possible to at least prefill a form, like opening the DS
and automatically transfer all the data from the journal or the EHR for this patient and you will
prefill a form, at best with 100% of the variables. At first it will be nothing, but latter 50, 70, 80%
of all the variables that we have to fill in per visit from the DS, it will be fetched directly from the
EHR”
80
“the EHR should be able to fill in these data and not all EHRs are capable of doing that yet. Also
the MS QR is a national registry, which means we will have to communicate though
tjansteplatform. We do not care what the EHR is or where it is, but tjansteplattform will have
hit, hit and then miss, miss, miss, for some patients that are in a certain region”
“MS QR will be connect to tjansteplattform but it is not going to happen tomorrow. Hopefully
sometime, quite soon”
Free text in the EHRs and freedom of input in the QR.
“But there are not so many mandatory things to fill in the EHR and you don’t have to fill it in, in
a structured way. What you can do is say that patient was here that date and got this medicine,
which makes it quite impossible to structure the data and transfer it to the DS. So it also
depends on the structure on the EHR, or the possibility to structure the free text and then send
it. So a lot of question marks of how much data you can actually get in the forms”.
“The basic problem is that some people like to enter a lot of staff in the DS. Which makes it
difficult to actually get users or doctors’ use the system. So I think here there should be a
minimum of data in the DS, because since it is done manually, it shouldn’t be overwhelming.
Because it is better to get 100% of 15 variables than 20% of 1000 variables. But I think that’s not
up to me”
“Not a lot of fields necessarily but there is a freedom on what you would like to enter here. If
you enter something in the MRI module, might not going to have a whole row of nulls, but that
could be”
“Everything in this DB, is up to the doctor or the nurse to enter the data, so you can’t look at this
DB and say that you have everything, or that you are missing something, because you actually
don’t know. You can only say this is what there is in the DB, what we have. You cannot draw any
conclusions about any missing data, compared to what?”
Legal limitations
“I think it will be a possibility later on that they (the patients) can say, this one should not be
entered. Until now it is the doctor’s choice to import the patient’s data”
“in order to send data from DS DB to the MS QR DB, the patient must give his consent for this”
“all the measurements and values in the QR are defined by the MS QR society. It is like a board,
they decide what goes in here”
“exactly a committee. Because my understanding is that the QR is not interested so much in the
patient entered data. It is QR for the MS healthcare and not so much for the patients in an
individual level. If things can be validated and analysis or conclusions can be drawn upon the
81
patients entered data maybe it could go in the QR sometime in the future, but maybe not right
now”.
Standards followed
“MS QR DB, is an SQL DB, mySQL DB. The structure off course is custom”
“ICD-10 (is used) absolutely. We are looking at SNOMED. It is not in the system right now, but
we are going to try and implement this quite soon”
“lab results, is just free text and numbers”.
“There is no messaging standards used. There is just an export like a transposition and an export
in the QR”.
Entering PGHD to the QR
“It could be possible (to store PGHD to the Patient DB). But…we would have a hard time, unless
you identify the patient in this system (patient DB) to actually import it to the DS DB
Question: You mean there should be a correlation again from zero.
Yes. Anyway, it is not as complex as it sounds, but there is anonymized data in the patient DB.
No personal ID no social security number”
“I think it (PGHD) should pass a legal barrier, before entered in the QR”.
“They (PGHD) could definitely stay either in the patient or the DS DB, or maybe a parallel DB to
the patient DB”
“One viable DB in order to upload the PGHD, could may be Hälsa för mig. Because I think that
the purpose of that is actually that you as a patient, you can upload any data you like to this
platform. I am not sure if you can do group data analysis, but maybe it could be the device that
you upload the data to and then get the data into the DS system through tjansteplattform from
Hälsa för mig DB”
82
Appendix 8
Capture and upload of the data in the cloud
There should not be a limit for the gateway only in the usage of smartphone. It could
well be a tablet or a laptop with the possibility of connection with Bluetooth.
BankID is a good idea, which can make the transfer of the data easier, since it does not
make the patient use only one device, but he can identify himself from any device that
uses BankID
Better to have a cloud in the middle, so that there should not be a different API for
different devices, iPhone/android. The best solution is the transfer of the data to a cloud
and then to the Patient DB.
We cannot talk for standards in the point of the transfer of the data from the gateway to
the cloud and from cloud to the Patient DB, since this is dependent on the APIs that will
be finally used in order to have the implementation.
There may could be a cooperation with the vendor of the WD and get data directly from
the cloud storage solution of the WD
Push function from the cloud
Probably some transformation of data will be needed, when they are transferred from
the cloud to the permanent storage into the DBs of Carmona.
Second stage of the model – From the cloud to the QR
Tjänsteplattform “rejected” for the moment, since it is not known when it will be in full
scale implementation. We cannot wait when the tjänsteplattform, or other solutions like
Hälsa för mig are ready, we should implement it with the reality that exists now and
allows us to make it that way
Model can work now like the one proposed, and in a later stage, adapt to the
tjänsteplattform usage.
We already get data from other statistical services in the Patient DB, like possible deaths
of MS patients, so we can easily gather also PGHD, either from a WD or applications of
self-assessment.
The data will have a separate logical position in the Patient DB
The data cannon get transferred immediately in the MS QR DB that is used today for the
needs of the QR (like research etc.)
An important reason for the DB that the data will be finally saved, is the scope of the
usage of the data. If the data is needed just to show a trend about the patient over time,
that means only some graphs, then the data are not needed to end up in the MS QR DB.
83
But if data will be used for research and further utilization, they could be stored in MS
QR DB or another equal DB
The key for the final model is the goal we want to achieve with the usage of the data. If
we do not decide what we want to do with the data we cannot say where these data will
be stored.
Vague regarding the further storage of the data – strongly connected to the reason for
which the data will be used.
General feedback regarding the models presented
We cannot say that one model is better than the other, they all have strong and weak
points.
The 3rd model can be immediately implemented
Feedback regarding the proposed PGHD for the QR
There is a lot of interest also in applications that can track cognition. The data which will
really help the QR are data for cognition, like from SDMT. There is interest also for
movement ability, but for fine motor skills, that means ability to perform tasks with
hands (9 hole peg test).
We would like to have a measurement like this, but doctors are skeptical, since patients
maybe report every possible deterioration as a relapse.
One of the participants spontaneously proposed exactly the same suggestion that was
between the proposals for the utilization of the possible PGHD entered. It was the
proposal about the correlation of sleep disorders with fatigue.
From the proposals made for PGHD to get tracked, the strongest objection was for stress
correlated with MS progression. Like, how could the progression of MS be measurable?
In physical or cognitive state? This should be clarified, but again the stress is not a factor
that could be correlated directly and clearly with MS.
A monthly distant meeting and one annual from close, regarding the issues of the QR
