Clinical Proof-of-Concept – A Evaluation Method forPervasive Healthcare Systems

Jakob E. BardramIT University of Copenhagen

Rued Langgaards Vej 7, DK-2300 Copenhagen, Denmarkbardram@itu.dk

ABSTRACTPervasive Healthcare – i.e. designing pervasive computingtechnologies for healthcare usage – is an especially promis-ing area within pervasive and ubiquitous computing re-search. However, it is extremely difficult to evaluate suchsystems because establishing clinical evidence for medicalbenefits would require longitudinal, randomized, double-blind, placebo-controlled trials involving a homogeneouspatient population and medical condition. This would notonly require huge resources in terms of clinical staff and pa-tient participation, but would also require the technology tobe fully developed and ready for large scale use. The lat-ter is simply not feasible when doing technological researchinto new types of pervasive healthcare technologies. In thispaper, I suggest the method of ‘Clinical Proof-of-Concept’as a method for evaluating pervasive healthcare technologiesin order to establish the clinical feasibility of the technologybefore entering large-scale clinical trials. The method hasbeen applied in a couple of cases and I report on lessonslearned from this.

INTRODUCTIONApplying Ubiquitous and Pervasive Computing technologiesfor healthcare purposes is gaining increasing interest and isgrowing into a research field of its own called ‘PervasiveHealthcare’ [3, 1]. The research questions and the technolo-gies being investigated within Pervasive Healthcare are quitediversified ranging from using biomedical sensor technologyfor patient monitoring and prophylactic treatment, to mo-bile and context-aware systems inside hospitals. PervasiveHealthcare has a lot in common with established medico-technical research areas like biomedical engineering, medi-cal informatics, and telemedicine, but is distinct in its funda-mental approach and goals; pervasive healthcare systems areoften designed for patients and not for clinicians, and theyembody technologies growing out of the ubiquitous com-puting research, including sensor technology, context-awareand mobile computing, large interactive displays, etc. Sim-ilar to Ubiquitous Computing research, Pervasive Health-

Copyright is held by the authors. Permission to make digital or hard copiesof all or part of this work for personal or classroom use is granted withoutfee provided that copies are not made or distributed for profit or commercialadvantage and that copies bear this notice and the full citation on the firstpage.UbiComp ’08 Workshop W2 – Ubiquitous Systems Evaluation (USE ’08),September 21st, 2008, Seoul, Korea.This position paper is not an official publication of UbiComp ’08.

care research is specifically targeted towards technology –i.e. aiming at understanding, designing, building, and testingnew types of pervasive computing technologies for health-care purposes.

A common methodological approach to ubiquitous comput-ing research is to design and implement a technical ‘Proof-of-Concect’ for a proposed new ubiquitous computing tech-nology or application, and subsequently evaluate this imple-mentation in a limited setup. Marc Weiser defined the con-cept of a technical Proof-of-Concept as:

The construction of working prototypes of the neces-sary infrastructure in sufficient quality to debug the vi-ability of the system in daily use; ourselves and a fewcolleagues serving as guinea pigs. [8].

Looking at the research questions posed by pervasive health-care, this research approach seems to be lacking some rigorin order to investigate whether the technology solve healthrelated challenges. We would, for example, never be able tounderstand or evaluate to which degree a technical prototypefor elderly people would be successful, if it is only tried outby our colleagues in a research laboratory.

From a medical perspective a technical proof-of-concept isnot acceptable for introducing new medical technology ortreatment. In most healthcare systems, clear clinical evi-dence needs to exist before a new medical technology is putinto use for patient treatment. Evidence-based medicine [7]is the clinical methodological approach for establishing thisevidence. Evidence-based medicine categorizes differenttypes of clinical evidence and ranks them according to thestrength of their freedom from the various biases that besetmedical research. The strongest evidence for therapeutic in-terventions is provided by systematic review of randomized,double-blind, placebo-controlled trials involving a homoge-neous patient population and medical condition. In contrast,patient testimonials, case reports, and even expert opinionhave little value as proof because of the placebo effect, thebiases inherent in observation and reporting of cases, anddifficulties in ascertaining who is an expert.

Such strong evidence is, however, impossible to obtain whilewe are still in the research and development phase of newtechnology. So an important question is how we can strike abalance between these two extremes; design and implementlimited technical proof-of-concepts which at the same time

are suited to provide sufficient clinical evidence for furtherresearch and development

In this paper, I suggest a methodological approach called‘Clinical Proof-of-Concept’ which is aimed at creating ini-tial clinical evidence for the medical benefits of a pervasivehealthcare technology. This approach has been used in acouple of cases and I will report on these cases, how the clin-ical proof-of-concept was carried out, and what we learnedfrom these cases.

The contributions of this paper is the presentation of themethodological approach of a Clinical Proof-of-Concept to-gether with specific examples of its use in two cases. Bysuggesting this approach, it is my aspiration that more per-vasive healthcare technologies can be subject to initial eval-uation and scrutiny before entering large scale clinical trials,while at the same time actually being put into test in a lim-ited real-world deployment. Using this approach, a more in-cremental and experimental approach to the construction ofpervasive healthcare technologies can be achieved, which inthe end will lead to developing more appropriate and usablepervasive healthcare technologies. At the same time, the ap-proach would enable us to reject and dismiss those technolo-gies, which show little clinical promises before large amountof resources are spent on developing the technology and run-ning clinical trials.

CLINICAL PROOF-OF-CONCEPTTo rephrase the definition from Marc Weiser, I am defininga Clinical Proof-of-Concept (CPoC) as:

The construction of working prototypes of the neces-sary functionality and infrastructure in sufficient qual-ity to investigate evidence for improving health in dailyuse for a suitable period of time; a limited but relevantset of people serving as subjects.

More specifically, the technology should be a working proto-type that is usable (but not necessarily user-friendly), workson its own, and is focused on addressing specific researchquestions. This technology should be deployed in a realclinical setup, should be used by real users (researchers arehands-off), for a short, but sufficient period of time, which –depending on the research question – may range from 1 dayto 3 months.

For example, you may want to test a system for monitoringhypertension and evaluate if users are able to control theirown blood pressure over time, thereby reducing hyperten-sion, which again – according to medical literature – have apositive effect on a wide range of heart diseases. In this case,a CPoC would involve a technical prototype which runs onits own and is able to monitor blood pressure, but it maynot be particular secure, robust, or integrated in a country-specific healthcare system. It should, however, be able to runwith limited interference from the researchers, while some‘Wizard-of-Oz’ techniques may be applied. The deploymentwould include a limited amount of people – e.g. 10 – whichis not statistically significant for hard medical evidence, but

sufficient for establishing the viability of the technical setupand its use in a real-world deployment. And the trial mayrun for a couple of weeks – rather than the months normallyrequired for a clinical trial.

The methods used during this CPoC should be targeted atcollecting evidence, which demonstrate that the technologyseems promising in addressing its specific goal. It may berelevant to gather initial clinical evidence for the medicalbenefit of the technology. For this purpose, trying to measuresome clinical effects is essential during the CPoC. For exam-ple, in order to establish any clinical effect in the monitoringof hypertension, blood pressure data may be compared overthe time span of the CPoC and questionnaires regarding thepatients’ awareness and handling of their blood pressure maybe issued and analyzed.

Even though the clinical evidence may be biased by differ-ent factors and hence not as strong as would be requiredin Evidence-Based Medicine, providing initial clinical evi-dence for the working of the technology is still essential inorder to justify further development and evaluation. Further-more, the Clinical Proof-of-Concept may simultaneouslywork as a ‘dry-run’ for testing the data collection methods,which later are to be used during the clinical trial. For exam-ple, if a questionnaire is handed out to the participants, thisquestionnaire and the timing of it may be subject to changebased on experiences obtained during the clinical proof-of-concept.

Apart from establishing initial clinical evidence, a core pur-pose of a CPoC is to investigate the usefulness and usabilityof the proposed solution. To a certain degree, I would ar-gue that this is the main purpose of a CPoC for two reasons.Firstly, the clinical benefit of a pervasive healthcare technol-ogy may be significantly diluted if the technology is hardto use for the patient. For example, it is obvious that if theblood monitoring technology is hard to use, then limited ef-fect on hypertension management may be found during theclinical trial. Secondly, it is essential to catch and remedysuch usability problems in an early phase before resourcesare invested in developing the technology, producing it inlarge numbers, and deploying it for a clinical trial.

These arguments may seem trivial. However, some sort ofusability problems are often hard to discover and are oftenunexpected. By running a CPoC which actually puts thetechnology to a test in a real-world setting with real usersfor a certain period of time, many of the more complex us-ability problem may surface. And often, ideas for changingand improving on the technology arise when seeing it in ac-tual use and by working closely together with the users tofind a solution to the problem.

Methods for usability inspection would typically be quali-tative in nature, involving observations, questionnaires, andstudies of perceived usefulness and usability.

Figure 4 show the temporal progression of research meth-ods as the technology is developed and mature. Time-wise,

Figure 1. The timing of a Clinical Proof-of-Concept isbetween a laboratory proof-of-concept and a full clinicaltrial.

a clinical proof-of-concept lies in between the technical lab-oratory proof-of-concept and a full-scale clinical trial.

CASESIn order to illustrate how a CPoC can be used in pervasivehealthcare research, I will use two cases as examples. Thefirst case is concerned with home-base blood pressure mon-itoring, and the second case is concerned with developingcontext-aware technologies for improving patient safety in-side the operating room. These two case are very distinct inmany respects – technology, users, deployment settings, andgoals – but as such, they illustrate the breath of the CPoCapproach.

Blood Pressure MonitoringThe first project was concerned with home-based monitoringof hypertensive patients. Hypertension is a direct cause of anumber of heart diseases, including congestive heart failureand stroke, and substantial clinical evidence indicates, thatfrequent blood pressure monitoring helps prevent hyperten-sion [6]. For this reason, many pervasive healthcare projectshave addressed hypertension. This project was done in 2002when state-of-the-art blood pressure monitoring was basedon a cuff. Our goal was to deploy the technology in a lim-ited pilot study and perform a CPoC (even though we didnot call it that at that time). The technology for home-basedmonitoring consisted of a suitcase with a traditional bloodpressure monitor, a PDA, and a GSM modem as shown inFigure 2.

In this project, the suitcase were given to the patients by theirgeneral practitioner (GP). The system had three main fea-tures: (i) it allowed the patient to measure the blood pressureseveral times a day and this data was sent to a central serverfor the GP to observe; (ii) the GP could prescribe medicinesand the patient could indicate that (s)he was complying tothe prescription; and (iii) it enabled communication betweenthe patient and the GP, using both text and voice messaging.

During the first months of a longer deployment period, wecarried out a series of interviews and field studies of thishome-based monitoring and treatment system. This study

Figure 2. A patient using the home-based monitoringsystem in a briefcase for monitoring her blood pressure.

was focusing on studying issues of medical treatment, di-vision of work, communication, patient self-understanding,and the technology in actual use [2]. Our study – in ac-cordance with most medical studies of home-based mon-itoring of hypertension – gave evidence that this kind ofblood pressure monitoring provides more accurate measure-ments. Our findings, however, also revealed that the relation-ship between the GP and the patient changed when this newcomputer-mediated home-based treatment for hypertensionwas introduced. More specifically, we found four specificaspects of this transformation caused by pervasive monitor-ing and treatment technology:

• A new division of work emerged, which transferred theact of monitoring and interpreting the blood pressure datafrom the GP to the patient.

• The medical treatment of hypertension and the life qualityof the patient was improved. However, new demands formonitoring the incoming data and the patient’s progres-sion in treatment were inflicted upon the GP.

• The communication pattern between the patient and GPwas fundamentally changed from a contextual rich con-versation to an asynchronous message exchange.

• Because the patient was more involved in the monitor-ing and treatment of hypertension, he or she became moreself-aware on the nature of high blood pressure and whataffects it.

This clinical CPoC was insufficient to establish clinical ev-idence for improved hypertension treatment of the patients.For this purpose, the time frame of the study was too short,the sort of methods applied insufficient for determining clin-ical evidence, the number of patients were too small, and nocontrol group was involved. The study, however, were suf-ficiently large to study, understand, and argue that this kindof home-based monitoring would transform the patient-GPrelationship and make the patient capable of managing theirown blood pressure in a more efficient way. And since pre-vious clinical studies have shown that regular self-conscious

attention to your blood pressure reduces the risk of hyper-tension, this was clearly a strong indicator that this kind oftechnology would be useful.

At the same time, the CPoC revealed a series of usabilityand deployment issues which needed to be looked into be-fore running larger scale trials involving a larger amount ofpatients and GPs. The technology were subsequently im-proved and deployed in a large clinical trial with 10 GPs,120 patients, and a control group.

Context-aware Patient SafetyThe Context-aware Patient Safety and Information System(CAPSIS) monitors what is going on inside the operatingroom and use this information to show timely medical datato the clinicians, and to issue warnings if any safety issuesare detected [4]. CAPSIS monitors events like the status ofthe operation; the status and location of the patient; loca-tion of the clinicians who are part of the operating team;and equipment, medication, and blood bags being used in-side the operating room. This information is acquired andhandled by a context awareness infrastructure, and a specialsafety service is used for overall reasoning which actions totake or warnings to issue. The goal is to supplement humansafety vigilance with a machine reasoning counterpart.

CAPSIS was deployed and tested in a CPoC where it wasused for one day by a full surgical team performing simu-lated operations inside an operating room. In total, 8 oper-ations were executed during the day, involving both opera-tions with no warnings as well as different types of warn-ings, including wrong patient, wrong operating table, wrongblood, and incomplete team. In addition, medical records,radiology images, and the operation checklist were pre-sented on displays using the context-aware triggers. A pic-ture from the CPoC is shown in Figure 3. Everything weredone exactly as real surgeries, except that no real patientswere involved and the acting patients were not sedated or ac-tually cut. The acting patients, were, however treated as anyreal patient, including being admitted to ambulatory surgeryand scheduled in the scheduling system.

The goal was to provide objective measurements on the use-fulness and usability of our design while, at the same time,investigate the detailed user reaction to the system and theuser interface in a more qualitative fashion. For this purpose,we used a multi-method evaluation setup where we (i) askedthe users to perform the operations while thinking aloud, (ii)investigated perceived usefulness and usability based on aquestionnaire [5], and (iii) made a semi-structured follow-up interview.

Based on this evaluation, the clinicians concluded that thesystem would be very useful for ensuring patient safety andwas very easy to use. Most of the patient safety issues mon-itored by CAPSIS were found to improve patient safety, andseveral of the findings resonate with the recommendationsfrom the state-of-the-art regarding patient safety. Moreover,the CPoC revealed a series of usability issues which wehad not captured previously, despite several prototyping ses-

Figure 3. The deployment of the system inside the OR;the surgeon and the sterile nurse read medical data onthe screen to the right while the scrub nurse interactswith the patient safety system on the screen to the left.

sions. By actually deploying the technology inside the OR,and asking the operating team to use the technology duringclose to real-world surgeries, a wide range of issues surfacedwhich would have not been found otherwise. Especially is-sues regarding the physical working environment of an ORand the tight teamwork taking place during surgery surfaced.Some examples of issues that were discovered during thisCPoC include;

• The user interface had to be improved in several place,including issues like coloring, highlighting, and font sizeon the screen due to the distance from the operating tableto the screens.

• The procedures regarding attaching a RFID enabled arm-band to the patient needed to be scrutinized because pa-tient safety now was depending on that this was done cor-rectly. If the wrong armband was attached to a patient,unpredictable and potential severe safety hazards may oc-cur.

• Better support for handling and registering scanning ofblood bags were needed. When moving from a limited testin a lab to a CPoC in the OR where a substantial volumeof blood may be needed, the existing method for checkingcorrect blood did not scale to e.g. 10-20 blood bags. Thereason for this was due to a number of highly interlinkedaspects, ranging from the organizational procedure for or-dering and getting blood, to the physical layout of the OR,and the way the RFID technology were working.

• Lack of triangulation, which is the medical safety termfor ensuring that a safety check is done by combining thepatient, the procedure, and the clinical staff. Even thoughthis was part of the overall systems design, triangulationdid not work inside the OR on the individual level.

• The operating team had to change their safety proceduresjust before surgery in order to leverage the capabilities ofthe system.

It is important to note, however, that this CPoC setup isnot providing ‘hard clinical evidence’ for improved patientsafety inside the OR. We do not know if this system – ifbuild and deployed – would improve on patient safety. Thiswould require a randomized clinical trial over a longer pe-riod of time involving a control group, which again wouldrequire a full working system ready for large-scale and long-time deployment. Providing such Evidence-Based Medicineis, however, not the purpose of a Clinical Proof-of-Concept;it is rather to investigate the feasibility of the proposed solu-tion for further development. By asking the involved clini-cians how they perceive the system’s potentials for improv-ing patient safety, we are given sound indications regardingthe feasibility and directions for further development.

Beside this indication of potential clinical evidence for im-proving patient safety, the core benefit from running thisCPoC is the different problematic issues regarding the cur-rent prototype which must be addressed before making alarger clinical trial. As illustrated above, these issues are amixture of technical, usability, physical, and team-orientedaspects which need to be addressed in concert. But most im-portantly, these complex and interrelated issues would prob-ably never have been found without running a CPoC. Thenext step would be to incorporate the suggestions for im-provement and then apply more rigorous clinical methodsfor evaluating the degree to which the system improves onpatient safety. Note, however, that the only reason for suchan investment is based on the fact, that the CPoC indicatedthat the system potentially would improve patient safety.

DISCUSSIONWhat have we learned from our use of clinical proof-of-concepts so far?

First of all, a CPoC reveals a wide range of technologicalproblems and issues. For example, in the blood pressuremonitoring project, the CPoC revealed all sorts of problemswith wires, handling software updates, and sustaining poweron the devices while not in use. In the patient safety project,the CPoC revealed all sort of issues ranging from the work-ing of the RFID technology to the use of the software onlarge touch-screens. Hence, a CPoC is useful in determin-ing the sort of technological issues which are related to real-world use by real users for a longer period of time and on alarger deployment scale.

Second, even though a CPoC seldom is done in a way whichjustify any ‘hard’ clinical evidence, it is still useful in or-der to both provide initial clinical evidence for a potentialmedical effect, as well as providing important informationon how this clinical effect should be collected. For exam-ple, the clinicians in the patient safety project unanimouslyagreed that the system had the potential for improving pa-tient safety inside the OR. This do not count as clinical ev-idence, but nevertheless it encourage further development.At the same time the CPoC revealed that the methods usedfor evaluating the system were appropriate for judging per-ceived usefulness, but they were not appropriate for provid-ing clinical evidence for the improvement of patient safety

during surgery. Hence, a new methodological setup is re-quired in any subsequent clinical trial.

Third, because the technology is deployed in a real settingfor a non-trivial period of time, a CPoC is well-suited forinvestigating the usability of a pervasive healthcare system.Especially non-trivial usability problems which arise fromcomplex interaction between different types of technologies,users, real deployment settings, and long-term use may bediscovered during a CPoC. For example, the blood-pressuremonitoring CPoC revealed that it was hard for some patientsto type a message to the GP and this functionality was hencechanged to use voice messages instead of text messages.And in the patient safety project, as wide range of usabil-ity issues regarding the user interface were found.

Fourth, due to the real-world deployment a CPoC helps re-veal and evaluate the physical usage of the technology. Thephysical aspects of the technology is especially important forpervasive healthcare systems since medical devices and sys-tems are notoriously tied to monitoring or influencing phys-ical properties of a human body or a physical environmentin homes or hospitals. For example, a wide range of is-sues regarding the physical handling of the blood-pressurecuff and the handling of the PDA were revealed during theCPoC. This subsequently lead to the design of a cartoon-likestep-by-step instruction card, which were place on the frontof the suitcase, as shown in figure 2. In the patient safetyproject, the physical layout of the OR, the physical handlingof patients, blood bags, and instruments turned out to havesignificant impact on the use of the system.

Finally, often pervasive healthcare systems needs to existand work in a larger social and organizational context. ACPoC is equally suited for initial investigation of the impactarising from this larger deployment context. Especially inthe blood-presure project we found a significant change inthe division of work and communication between the GP andthe patient, and the CPoC revealed some of the important de-tails of how the technology would potentially influence theway the treatment of hypertension were achieved. In the pa-tient safety project, the CPoC helped judge the fit betweenthe system and the complex and dynamic teamwork takingplace inside an OR.

CONCLUSIONIn this paper, I have proposed to apply a Clinical Proof-of-Concept as a methodological approach for evaluating perva-sive healthcare systems. A CPOC involves a focused studyin a real-world deployment setting, involving real patientsand users, while being limited in time, scope, and clinicalrigorousness in the methods applied. By being a steppingstone in the middle of a laboratory-based evaluation and afull-scale clinical trial, the CPoC is able to provide valuableinformation regarding the clinical applicability of the sys-tem, its usability, and issues regarding the physical and orga-nizational deployment of the system. In this way a CPoC is amore dedicated and cost-effective approach for establishinginitial clinical evidence as well as being a invaluable sourcefor improving the technology at a stage before resources are

invested in final development and clinical trials.

AcknowledgmentsThe hypertension project was done together with AndersThomsen and Claus Bossen. The context-aware safety sys-tem for operating rooms were done together with NielsNørgaard and the surgical staff at Horsens Sygehus in Den-mark.

REFERENCES1. J. E. Bardram. Pervasive healthcare as a scientific

dicipline. Methods of Information in Medicine,3(47):129–142, 2008.

2. J. E. Bardram, C. Bossen, and A. Thomsen. Designingfor transformations in collaboration: a study of thedeployment of homecare technology. In GROUP ’05:Proceedings of the 2005 international ACM SIGGROUPconference on Supporting group work, pages 294–303,New York, NY, USA, 2005. ACM Press.

3. J. E. Bardram, A. Mihailidis, and D. Wan, editors.Pervasive Healthcare: Research and Applications ofPervasive Computing in Healthcare. CRC Press, 2006.

4. J. E. Bardram and N. Nørskov. Designing Context-awareSafety Systems for the Operating Room. In Proceedingsof Ubicomp 2008: Ubiquitous Computing, Seoul, Korea,Sept. 2008.

5. F. D. Davis. Perceived usefulness, perceived ease of use,and user acceptance of information technology. MISQuarterly, 13(3):319–339, September 1989.

6. M. A. M. Rogers, D. A. Buchan, D. Small, C. M.Stewart, and B. E.Krenzer. Telemedicine improvesdiagnosis of essential hypertension compared with usualcare. Journal of Telemedicine and Telecare, 8:344–349,2002.

7. D. L. Sackett, W. M. Rosenberg, J. A. Gray, R. B.Haynes, and W. S. Richardson. Evidence basedmedicine: what it is and what it isn’t. BMJ,312(7023):71–2, 1996.

8. M. Weiser. Some computer science issues in ubiquitouscomputing. Communications of the ACM, 36(7):75–84,1993.