Intel® Technology Journal: Enabling Healthcare in the Home

Transcription

9 781934 053232
7
35858 21143
7
$49.95 US
Copyright © 2009 Intel Corporation. All rights reserved. Intel, and the Intel logo, are trademarks of Intel Corporation in the U.S. and other countries.
ITJ9-3_Cover_BFC_39spn_090409.indd 1
SEPTEMBER 2009
Enabling Healthcare in the Home
vol 13 | issue 03 | SEPTEMBER 2009
ISBN 978-1-934053-23-2
Intel® technology journal | ENABLING healthcare in the home
More information, including current and past issues of Intel Technology Journal, can be found at:
http://developer.intel.com/technology/itj/index.htm
Intel® Technology Journal
9/4/09 8:28:45 AM
About the Cover
Enabling Healthcare in the Home is the theme of
the Intel Technology Journal, Volume 13, Issue 3.
The physician in the foreground (1) is remotely
performing a house call. The doctor is able to see
the patient (2) and to obtain diagnostic information,
such as blood pressure and pulse vitals. The patient
is able to remain at home, which is helpful and
efficient for those with ambulatory or transportation
issues. Next door (3) is an elderly person who can
safely live independently because the home is outfitted with sensors (the yellow spots) that monitor
motion. Family caregivers located elsewhere can
be aware that this individual is performing routine
tasks. Upstairs is (4) someone sleeping. Sensors
measure nighttime activity, which can be an indicator of health risk. Also
upstairs (5) is a child or an elderly person for whom reading is difficult.
The child or elder can snap-shot a page and listen to the words. Thus,
technology can enable healthcare in the home for all ages.
9/4/09 8:28:46 AM
Intel® Technology Journal | Volume 13, Issue 3, 2009
Intel Technology Journal
Publisher
Richard Bowles
Managing Editor
David King
Content Architects
Doug Busch
Eric Dishman
Program Manager
Stuart Douglas
Technical Editor
Marian Lacey
Technical Illustrators
Richard Eberly
Margaret Anderson
Technical and Strategic Reviewers
Steve Agritelley
Alan Boucher
Doug Bugia
Doug Busch
Eric Dishman
Farzin Guilak
Kristina Kermanshasche
George Korinsky
Brad Needham
Kevin Rhodes
Intel® Technology Journal | 1
Copyright © 2009 Intel Corporation. All rights reserved.
ISBN 978-1-934053-23-2,
ISSN 1535-864X
Volume 13, Issue 3
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical,
photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either
the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center,
222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the
Publisher, Intel Press, Intel Corporation, 2111 NE 25th Avenue, JF3-330, Hillsboro, OR 97124-5961. E-mail: [email protected].
This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold with the understanding
that the publisher is not engaged in professional services. If professional advice or other expert assistance is required, the services of a competent
professional person should be sought.
Intel Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights that relate to the
presented subject matter. The furnishing of documents and other materials and information does not provide any license, express or implied, by estoppel
or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights.
Intel may make changes to specifications, product descriptions, and plans at any time, without notice.
Third-party vendors, devices, and/or software are listed by Intel as a convenience to Intel’s general customer base, but Intel does not make any
representations or warranties whatsoever regarding quality, reliability, functionality, or compatibility of these devices. This list and/or these devices may be
subject to change without notice.
Fictitious names of companies, products, people, characters, and/or data mentioned herein are not intended to represent any real individual, company,
product, or event.
Intel products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications.
Intel, the Intel logo, Celeron, Intel Centrino, Intel Core Duo, Intel NetBurst, Intel Xeon, Itanium, Pentium, Pentium D, MMX, and VTune are
trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
†Other names and brands may be claimed as the property of others.
This book is printed on acid-free paper.
Publisher: Richard Bowles
Managing Editor: David King
Library of Congress Cataloging in Publication Data:
Printed in the United States
10 9 8 7 6 5 4 3 2 1
First printing September 2009
2 | Foreword
INTEL® TECHNOLOGY JOURNAL
Improving Healthcare Through Technology
and Innovation
Articles
Foreword�� 4
Powering Healthcare Visions: Taking Advantage of Complexity, Connectivity, and Consumerism�� 6
From People to Prototypes and Products: Ethnographic Liquidity and the
Intel Global Aging Experience Study�� 20
Adapting Technology for Personal Healthcare�� 40
Healthcare IT Standards and the Standards Development Process: Lessons
Learned from Health Level 7�� 58
Healthcare Information Integration: Considerations for Remote Patient Monitoring�� 80
Personal Health Device Interoperability�� 104
A Common Personal Health Research Platform — SHIMMER™ and BioMOBIUS™�� 122
Gathering the Evidence: Supporting Large-Scale Research Deployments�� 148
Assistive Technology for Reading�� 168
Developing Consumer and IT Platforms in a Regulated Medical Device Environment�� 188
Table of Contents | 3
Foreword
Douglas F. Busch
Vice President
Chief Technology Officer
Digital Health Group
Intel Corporation
Eric Dishman
Intel Fellow
Digital Health Group
Intel Corporation
Fundamental medical science has made enormous strides over the past several
decades, and the length and quality of life in developed countries has improved
remarkably. However, trends in demographics, lifestyles, and treatment
practices are making our healthcare systems unsustainable. Improving access
to healthcare and controlling healthcare costs are two of the most contentious
current issues in United States politics, and are a huge concern in most other
countries also. Better use of technology in healthcare is an obvious strategy to
help solve these problems by applying innovation to how and where we deliver
care.
to how and where we deliver care.”
Science and technology have been applied aggressively to clinical diagnostics
and treatment. Diagnostic imaging, advanced surgical techniques, and
sophisticated pharmaceuticals have all had strong positive benefits. We have not
yet seen the benefits of applying everyday technologies that we take for granted
in other aspects of our lives, though. Much attention is now being given to
applying information technology to record keeping and communication in
clinical settings. The recent American Recovery and Reinvestment Act (part
of the 2009 economic stimulus package) focuses strongly on deployment and
meaningful use of Electronic Medical Records.
“We need to make home health
This is not enough. To really impact the availability and cost of healthcare, and
improve the quality of our citizen’s lives, we need to shift some of the focus of
healthcare from the clinical setting to the home. Just as much of banking has
moved from marble lobbies filled with tellers to a self-service model enabled
by technology, we can use readily-available technologies to move some aspects
of healthcare from clinical settings to the home. We can also use technology to
allow our aging population to stay in their homes longer, living independently.
Both of these approaches have the potential to improve quality of life and
reduce the cost of providing the healthcare and living assistance our population
needs. We need to really understand how to use technology effectively for these
purposes, and we need to adapt common technologies for successful use in
home settings. We need to make home health technology simple, unobtrusive,
and low cost, while protecting the security, privacy, and safety of our most
vulnerable family members.
“Better use of technology in healthcare
is an obvious strategy to help solve
these problems by applying innovation
technology simple, unobtrusive, and
low cost, while protecting the security,
privacy, and safety of our most
vulnerable family members.”
4 | Foreword
In this issue of the Intel Technology Journal, we hope to provide a broad
perspective on the use of technology for delivering healthcare at home.
Dr. Mike McGee, a noted physician, speaker and author, describes a vision for
lifelong healthcare delivered at home. Intel researchers describe their work and
some of the conclusions reached over several years gathering ethnographic data
and conducting pilot studies of home-based sensor networks. The leaders of
two major heath standards organizations describe the approaches being taken
to create interoperability of data and devices for healthcare. Lessons learned
about integrating healthcare data systems are shared by a team developing
health data middleware. Intel’s experience entering the medical device
product development industry is summarized by the leaders of our product
development groups. The design team responsible for building an assistive
device for reading disabilities shares their approach and learned lessons.
“We hope to provide a broad
Intel is both a long-standing member of the aging research community and a
new participant in the medical device community. We hope that by sharing our
insights, and those of our collaborators, we can encourage the development of
powerful, easy-to-use technology for home healthcare and independent living.
We hope that we can also stimulate investment in — and innovation for —
home-based care industries through broad-based R&D collaboration, standards
development, and political advocacy to ignite this important marketplace. Our
future, and that of our children, depends on dramatically improving access
to healthcare and reducing cost, which we believe is achievable if we can “go
home again” by using technology and innovation to reimagine how we deal
with the epidemics of chronic disease and injury that we all face from the
enormous success of our global age wave.
“We hope that we can encourage the
perspective on the use of technology for
delivering healthcare at home.”
development of powerful, easy-to-use
technology for home healthcare and
independent living.”
“Our future, and that of our children,
depends on dramatically improving
access to healthcare and reducing cost.”
Foreword | 5
Powering Healthcare Visions: Taking Advantage of
Complexity, Connectivity, and Consumerism
Contributors
Mike Magee, MD
Opinion
Over the past ten years, the World Health Organization and other groups have
been actively engaged in trying to answer the question “What is health?” A
large part of this thought process has involved defining what health is not. It is
not the healthcare system. It is not the reactive elimination of disease. It is not
a simple commodity to be weighed against all other commodities in society. It
is different from these things, and it is more than these things.
“A large part of this thought process
has involved defining what health is
not.”
Health is universal and common to the people of the world, independent of
geography, race, income, gender, and culture. Health is an active state of wellbeing that encompasses mind, body, and spirit. It is the capacity to reach one’s
full human potential, and, on a larger scale, the key that unlocks a nation’s full
productivity and potential for development.
The Modern Health World: Shaped By Intersecting
Megatrends
To lead and innovate in today’s healthcare world requires a modern vision
that is based on a highly strategic understanding of the major intersecting and
mutually reinforcing elements shaping health worldwide. Among these are
aging demographics, the growth in home-based caregivers, the dual burden
of disease, the Information Revolution, and consumer empowerment and
activism.
“By 2030, there will be over a million
United States citizens over 100.”
For most people involved in healthcare, aging equals numbers (how many
people are over 65, how many are over 85, and so on). But aging is not
about the aging population only. It is more complex than that. Fifty percent
of current sixty-year olds in the United States have a parent alive, and by
2030, there will be over a million United States citizens over 100. Before our
eyes, the American family is growing from three generations to four and five
generations. In 25 percent of American homes, a non-professional, family
caregiver works without pay and without support to manage frail parents and
grandparents on the one hand, and immature children and grandchildren on
the other. (I call these “informal” caregivers, as opposed to “formal” caregivers,
those who are trained and paid for what they do.) Almost all of these caregivers
are third-generation women, ages 40 to 70. When we look at the whole
question of providing healthcare, we must address these family dynamics
efficiently and effectively, and our solutions must bring support and relief to
beleaguered home-based informal caregivers.
6 | Powering Healthcare Visions: Taking Advantage of Complexity, Connectivity, and Consumerism
Coincident with an aging society is the Internet, an incredible tool. When
combined with ever-expanding computing power, remarkably innovative
processor technologies, broadband, wireless, and converging powerful
applications pushing massive amounts of information at lightning speed, the
Information Revolution gives us a glimpse of what is possible in a modern
world in terms of health and healthcare. The true significance of the Internet,
however, in this context, is that it ignores geography, and in doing so, breaks all
the rules governing communication: who gets what information from whom,
and for what purposes.
Regina Herzlinger at Harvard Business School first suggested a consumerdriven, healthcare model nearly 30 years ago. She and others at the time saw
a disconnect between those who paid for the care and those who consumed
it. It was clear to all that consumers of healthcare were often at a disadvantage
because they lacked adequate information to support decisions. Three decades
later, with the support of new information technologies, we see a very different
reality. Doctors, nurses, and hospitals seem to agree that “the best patient is
an educated patient.” They acknowledge that paternalism must give way to
partnership. It must be teams over individuals. There must be mutual decision
making. Most people would agree that these are all good things. However, our
access to health information is leading us into health activism, led mostly by
our informal family caregivers who labor as both providers and consumers of
healthcare in nearly 25 percent of all American homes: they have no formal
support or even acknowledgment from healthcare providers. For them, lack of
healthcare information is not what’s literally killing them. Lack of a support
system is killing them.
“Doctors, nurses, and hospitals seem
to agree that ‘the best patient is an
educated patient.’ ”
“Our access to health information is
leading us into health activism.”
Finally, an aging population, the Information Revolution, and the consumer
health movement intersect and reverberate within the context of a global
interconnected world community. High-speed travel, overnight delivery,
cultural integration, the rapid spread of inter-species microbes, and the
mass marketing of products, good and bad, have created a wide range of
health challenges. The developing nations struggle with warfare, migration,
famine, child mortality, and infectious diseases, while the developed world
is overwhelmed with largely preventable chronic diseases. As the developing
world exports the next influenza virus, the developed world returns the favor
by marketing tobacco and the American diet to developing nations. I believe
that together we share a dual burden of disease and a range of environmental
threats to our health from global warming to scarcity of clean, safe water.
Rather than fighting these accelerating trends that are connecting our
world, opening up access to health information, but also making our world
increasingly complex, we must embrace them. Our vision must be sufficiently
powered to take advantage of complexity, connectivity, and consumerism.
“As the developing world exports the
next influenza virus, the developed
world returns the favor by marketing
tobacco and the American diet to
developing nations.”
Powering Healthcare Visions: Taking Advantage of Complexity, Connectivity, and Consumerism | 7
The Power is Shifting
“I present here five visions
sufficiently powered to guide a true
transformation in our health.”
Clearly, healthcare reform is in the air. Whether such reform can positively
affect our health, however, remains to be seen. For true reform to take place,
powerful visions must be joined by cross-sector innovation to serve, humanize,
and realize future human potential. I present here five visions sufficiently
powered to guide a true transformation in our health and to encourage crosssector collaboration among traditional healthcare organizations and technology
leaders, such as Intel, and home health caregivers with existing positions in
American homes.
Vision 1: Home-Centered Healthcare
“We have been unable to create
or manage a more inclusive and
anticipatory healthcare system.”
Nearly 100 percent of the assets we currently include in our definition of the
healthcare system have little to offer us, in their current form, that would
help in the build-out of a truly preventive healthcare system. I am including
assets such as the bricks and mortar of our hospitals and our patient offices;
our human resources as embodied in our training, roles, responsibilities,
and payment incentives; our educational curricula; and our continuously
reengineered processes targeted at in-patient safety and efficiency. These assets
are original, or second or third iterations, of a century-old interventional care
system that stubbornly survives, largely in its original form, because we have
been unable to create or manage a more inclusive and anticipatory healthcare
system.
Prevention of illness is grounded in education and behavioral modification.
It begins before birth and extends beyond death. Let me explain: the parents’
nutritional status as well as their use of alcohol, drugs, and cigarettes affects
fertility, as well as conception and in-utero development. On the other end of
one’s life, friends and family predictably suffer grief and anxiety at the death
of an individual, and these friends and family can often benefit from formal
bereavement support services.
“To be successful, therefore, a
preventive healthcare system must
To be successful, therefore, a preventive healthcare system must take advantage
of multi-generational relationships to provide multiple, repetitive inputs in
real-time that allow micro-adjustments in a person’s daily life. Such a system
demands intimately informed, highly motivated, and deeply committed
individuals willing to gently prod those under their charge toward health and
wellness. I believe that the goals of a preventive healthcare system require
guiding hands and a pervasive presence across several sectors: family and
community linkages, and the ability to efficiently lay out lifecycle plans
and execute lifespan management on the one hand, and ensure adherence
to palliative treatment plans for patients with chronic disease on the other.
Realizing this vision of a truly preventive healthcare system will require an
integrated approach to care delivery, supported by cross-sector collaboration.
take advantage of multi-generational
relationships.”
Beginning with New Technology
In the build-out of this new healthcare system, there is only one location that
is both geographically identifiable and politically viable as a candidate: the
home. Most Americans have a very favorable view of the home and its value
to quality of life. As a result, politicians frequently embrace the imagery of
“home” and are likely to be willing to invest (through legislation and other
means) in the creation of healthier homes. While the home may be where the
heart is, it is most certainly not currently where the health is, and in this way
it is the optimum site for constructive change to take place in our health and
healthcare.
I first began to think about the “moldability” of the home when I saw a
remarkable exhibit at the World Fair in New York in 1964. As a 16-year-old,
I remember sitting in the revolving theatre and witnessing the marvels of
technology. The audience was transported to what life was like in 1904 and
then brought forward through the decades to 1964, and then 1984, 20 years
into the future, showcasing how technologies and products helped to improve
our lives and would continue to improve our lives in the future. The exhibit
convinced me that toasters and refrigerators had truly improved our lives. Can
we leverage technology today to do the same for our health? America views
homelessness as a social failure, and we have begun to view “healthlessness” as
a social failure also. It doesn’t have to be that way. If we can leverage all kinds
of technology, from diagnostic and imaging to entertainment and financial, to
equitably re-outfit and at least partially improve the health of people in their
homes, I believe that we can efficiently re-center our healthcare system in the
home.
“If we can leverage all kinds of
technology, I believe that we can
efficiently re-center our healthcare
system in the home.”
Moving into the Home
The primary health information loop in our current healthcare system extends
from a hospital to a physician’s office and back. The home is an after-thought.
If you wish to obtain healthcare, you must leave your home and enter the
hospital-office loop. What if technology allowed us to change the trajectory of
that loop so that it goes from home to care team and back to home?
In this new approach, informal caregivers would become fully enfranchised
members of physician-led and nurse-directed care teams. These family
caregivers would not only be linked virtually to their multi-generational
families and to their care teams, but also to other informal family caregivers,
thereby effectively addressing the profound sense of isolation that comes with
the informal caregiver role. A wide range of secondary loops would evolve from
generalist to specialist, from clinician’s office to hospital, and from care team to
insurer or pharmacy. However, the primary loop, where data would originate
and from which privacy access would be granted, would be home-centered.
“In this new approach, informal
caregivers would become fully
enfranchised members of physician-led
and nurse-directed care teams.”
“The healthy home would also have
ubiquitous, low-cost sensors that
could track motions, actions, and
interactions.”
The data flowing out of the home of the future would be rich, varied, realtime, and widely available. It would include vital signs and diagnostic and
imaging results sent wirelessly to care teams. The healthy home would also
have ubiquitous, low-cost sensors that could track motions, actions, and
interactions. The data produced by these sensors would be interpreted by
artificial intelligence software and measured against predicted healthy living
plans. The results would be fed in a continuous stream to the care team. The
feedback loop would consist of a human team partner communicating through
a friendly interface of one’s choice, such as a wristwatch, phone, radio, TV, or
computer: this interface would act as a guide and companion. For example, the
interface might remind the person to bathe if he or she had forgotten to do so;
to increase fluid; to alter diet or to exercise; to take medication or vary dosage
that day; or even to call his or her daughter as promised.
The Ideal Scenario
“For example, the interface might
remind the person to take medication
or vary dosage that day.”
Beyond home healthcare for our aging population, this model would make it
possible for more healthcare to take place in the home for all the generations
within the home. Ten outcomes can be skillfully integrated into my vision of a
calm, well-organized, and healthy home:
1. A home health manager, previously the informal family caregiver, is
designated for each extended family.
2. Nearly all Americans have health insurance, and a universal, integrated
medical information highway is constructed primarily around the patient,
and integrated with caregivers, rather than the other way around.
3. The majority of prevention, behavioral modification, monitoring, and
treatment of chronic diseases takes place at home.
4. Physician-led, nurse-directed, virtual health networks of home health
managers provide a community-based, 24-hour, seven days a week, clinical,
educational, and emotional support team.
5. Healthcare insurance premiums for families are lower due to expert
performance of the home health manager, as reflected in evidence-based,
outcome measures of family members.
6. Basic diagnostics, including blood work, imaging, vital signs, and
therapeutics are performed by the home health manager and transmitted
electronically to the physician-led, nurse-directed educational network
which provides feedback, coaching, and treatment options as necessary.
7. Sophisticated behavioral modification tools, age adjusted for each
generation, are present and utilized in the home. These are funded in
part by diagnostic and therapeutic companies that have benefited from
expansion of insurance coverage and health markets, as early diagnosis and
prevention takes hold.
8. Physicians have more time to respond to health issues that truly require
an office visit, as more and more health concerns are increasingly
managed in the home. Monetary compensation for physicians increases in
acknowledgment of their roles in managing clinical and educational teams
and multi-generational complexity. Nursing school enrollment goes up, as
the critical role as educational director of home health manager networks
becomes a major magnet for the profession.
9. Family nutrition is carefully planned and executed; activity levels of all five
generations rise; weight goes down; cognitive functioning goes up; mental
and physical well-being are also up.
10. Hospital size continues to be reduced to appropriately meet the needs
of the community. Scientific advances allow earlier diagnosis and more
effective treatment, making the need for hospitalization increasingly rare.
Hospitals are more specialized and safer: that is, the concentration of
specialized services in Centers with high volume and expertise ensures safer
outcomes from select procedures.
Vision 2: Reconnecting the Family — Unlocking
Human Capital
When virtual health networks first appeared, clinical visionaries at the time
imagined an age of “telemedicine.” Dreamers thought the most pressing
application for these networks would be to connect knowledge and skills in
developed nations with pressing needs in the developing world. In reality,
we now understand that the true purpose of innovative hardware and
software, combined with pervasive broadband and wireless networking, is not
connecting the developed with the developing world, but rather to integrate
knowledge and skills in our own homes.
“The true purpose of innovative
hardware and software is to integrate
knowledge and skills in our own
homes.”
If we can reconnect the multigenerational American family, we can plan
efficiently for health and reorganize community resources, thereby addressing
both accessibility and affordability of health resources. If the lessons learned
in one generation can benefit other generations downstream, and if we can
efficiently utilize a multi-purposed health workforce, we will be able to afford
wellness, prevention, and scientific and technologic progress in our healthcare
and our health.
Segmentation as a Strategy No Longer Works
The most pressing health demographic in the United States and worldwide
is aging and its associated burden of chronic disease. This is not news. We
have seen it coming and tried to plan for it. For decades our training schools,
hospitals, regulators, insurance industry, housing industry, legal system, longterm care providers, and elder advocacy associations have focused on our aging
populations and their unique needs and vulnerabilities.
“We will be able to afford wellness,
prevention, and scientific and
technologic progress in our healthcare
and our health.”
“We must now use technology and
social networking to aggressively
reconnect the generations within the
modern family.”
Rather than segment the American family into old and young, we must now
use technology and social networking to aggressively reconnect the generations
within the modern family. By doing this, I believe that we can manage the
complexity, mobility, and health data of the modern family, and we can
distribute the responsibility for taking care of our health, as we move toward
the provision of universal healthcare.
Five Strategic Problems with Segmentation
First off, generational segmentation within a family, especially as the number
of people over 65, 85, and 100 continues to grow, becomes increasingly
problematic. For one thing, it pits one generation against another in a “civil
war of health financing,” that, absent coordinated efficiencies, creates a
downward cycle with all roads leading to health rationing.
“Generational segmentation traps
family learnings and health traditions
in multiple intergenerational divides.”
A second problem with generational segmentation is that it traps family
learnings and health traditions in multiple intergenerational divides. For
example, the 58-year-old, third-generation mother caring for her fourthgeneration 82-year-old mother with a fragile fracture from osteoporosis,
should ideally not only be an experienced and sympathetic caregiver, but also
a wise source of health information. While she is focusing on her mother’s
independence, dignity, and pain control, she should also be asking “How can
I avoid becoming vulnerable to the same disease as my mother?” Her research
and responses to questions of her doctors and other caregivers should tell her
that silent osteoporosis exists in 52 percent of third-generation women by age
50, which is to say, she herself is vulnerable and should have a bone scan.
Her research should also make her aware of her own 27-year-old daughter’s
vulnerability, since 98 percent of a woman’s skeleton is formed by age 20.
Further, it should bring her 5-year-old granddaughter’s activities into sharp
relief, since diet, exercise, and health-related behaviors in these early years
determine whether this first-generation family member’s skeleton will be in
good shape 15 years from now. Thus, in an enlightened, connected multigenerational family committed to each other’s health and well-being, health
learnings should continually and seamlessly flow down the inter-generational
ladder, with the goal of constantly shrinking the entire family’s future disease
burden.
“A third problem is that informal
family caregivers are trapped in a
cavern of social isolation.”
A third problem inherent in a segmented family care system is that informal
family caregivers are trapped in a cavern of social isolation. Many ignore
their own health and become ill during this period. Some die before those for
whom they are caring. They are disconnected from the formal care team and
from other informal family caregivers who struggle in isolation themselves.
Finally, they are often disconnected from their siblings and from children and
grandchildren, as the chaos, depression, and complexity of what they are doing
overwhelms them.
A fourth problem that affects the health and healthcare of a generationally
segmented family is that such segmentation works against the adoption of
electronic health records and electronic health planning. These electronic
records and plans are required to move us from a system of intervention to one
of prevention, and they are the tools that will propel us ahead of the disease
curve, by customizing and personalizing individual health planning.
“Segmentation works against the
adoption of electronic health records
and electronic health planning.”
A fifth and final argument for family connectivity is that it allows us to better
define the human resource needs for a modern healthcare team; emphasizes
individual roles and responsibilities; better assigns and utilizes these human
resources with an eye toward multi-use for cross-generational assessments and
services; and it enables a more informed application of unique community
resources to fill in the gaps where they exist.
Vision 3: Lifespan Planning Record — An Organizing
Planning Platform
To manage the complexity of our multi-generational families and to make
optimum use of our increasingly connected world requires an organizing
platform with sufficient power and flexibility to adjust in real-time, while
customizing and personalizing strategic health planning. Over the last decade,
the discussion about healthcare records has focused on converting paper-based
patient records of hospitals and doctors into electronic medical records (EMR).
The goal was to improve accuracy and efficiency, a worthy goal. However,
as this conversion process began, it became increasingly clear that what
constituted a “Record” was not only what was in hospitals’ and doctors’ files.
Rather, much of the real data on health resided with the patient; the EMR was
only part of the overall health picture. Thus, the concept of a “Personal Health
Record” (PHR) began to emerge, and this PHR may well someday subsume
the focus on an EMR.
“The concept of a ‘Personal Health
Record’ (PHR) began to emerge.”
An Integrated Long-Term Plan
I believe that in a truly preventive system, “health” is not a collection of latestage, reactive interventions. Rather, I believe that health should be defined as
a life fully lived — hopeful, productive, fulfilling, rewarding, and manageable.
The determinants of such a life begin before birth, embedded in the healthful
behaviors of one’s future parents, and are extended beyond death to one’s
survivors.
“I believe that health should be
defined as a life fully lived — hopeful,
productive, fulfilling, rewarding, and
manageable.”
Death
ears)
Birth
00 y
Life Plan (1
Figure 1
Source: Intel Corporation, 2009
Considering this broader view of health, the right concept for our health record
system should be a Lifespan Planning Record (LPR), a virtual online organizing
scaffold for health information and health planning.
The LPR for a single individual born today would extend out at least 100 years.
It would include all of the baseline medical information needed by patients,
and much more. It would consider economic, social, educational, and spiritual
goals and milestones as well as medical and scientific objectives.
“The LPR for a single individual born
today would extend out at least 100
years.”
Born today, the newborn child’s LPR would already contain a great deal
of data. Some reasonable compilation of the health records of parents,
grandparents, and siblings would be represented. Future diagnostic and
preventive therapeutic measures, based on familial information, would be
flagged on the timeline. Print, video, and graphic information from other
accessible intelligence databases would be seamlessly interwoven for easy use by
the people caring for each other and this new global citizen.
As time passes, this “living” record would grow and adjust to assist in
informed decision making, preventive behavior, and full and complete human
development.
Obviously, many issues will need to be sorted out in order for such a vision
to be realized, not the least of which are confidentiality, patient privacy, and
control over records. However, the bottom line is that as quickly as the EMR
is being subsumed by the PHR, the PHR is now being subsumed by the need
for an LPR. The LPR is the best way to move us toward a preventive healthcare
system.
“Future diagnostic and preventive
therapeutic measures, based on
familial information, would be
flagged on the timeline.”
Vision 4: Collapsing Databases — Accessing and
Integrating Knowledge
If the home is the center of our future healthcare universe, the connected
family an integral member of the health delivery team, and the LPR its
organizing framework, where will the health knowledge come from and how
will it be used to the best advantage?
“In order for healthcare consumers
Three enormous health databases are currently in the process of becoming
available electronically and therefore, easily accessible. The first of these is the
Clinical Research Database (CRD). Access to the latest information from
research discoveries is critically important as we shift more responsibility
for decision making to consumers’ shoulders. Health product companies
appreciate that anything short of full and immediate disclosure of all study
results could increase liability into the future and run the risk of collapsing
a successful product (Merck’s Vioxx drug is a case in point) Moreover,
in order for healthcare consumers to have full trust in their physicians’
recommendations, they need to have full disclosure regarding conflict of
interest: if a researcher or physician receives payment for doing drug or product
research and giving talks in support of that product, device, or drug, then
consumers need to know this. As a result, therefore, of conflict of interest
concerns and legitimate health consumer desires for early access to discovery
information, major research databases are moving toward open transparency.
full disclosure regarding conflict of
For better or worse, the public will soon have ready access to the vast
majority of positive and negative results at the time of completion of medical
research efficacy and effectiveness studies of new products and health devices
studies. These results will be electronic and therefore capable of being widely
distributed. In addition, the American people, as part of good citizenship, will
soon be able to voluntarily contribute their de-identified health information
to nationally coordinated Clinical Effectiveness Research, effectively becoming
data sources and thus co-contributors in the ongoing effort to improve health
in America.
“American people, as part of good
The second database is the Continuing Medical Education (CME) database
which will also soon be widely accessible. In fact, nearly 20 percent of the U.S.
CME database is already electronic and has been demonstrated to be effective.
It is likely that within ten years, the vast majority of the CME database will
be accessible and will be applied in real-time rather than in episodic segments.
Hand-held devices are increasingly standard medical equipment in caring
encounters, providing immediate database support to the patient-physician
relationship during the evaluative and joint decision-making process. This
allows experts to quite confidently predict that in a preventive healthcare
system, where information is overwhelmingly the dominant healthcare
product, CME will be seamlessly integrated into the whole doctor-patient
encounter and become an integral part of the diagnosis and outcome.
to have full trust in their physicians’
recommendations, they need to have
interest.”
citizenship, will soon be able to
voluntarily contribute their deidentified health information to
nationally coordinated Clinical
Effectiveness Research.”
“CME will be seamlessly integrated
into the whole doctor-patient
encounter and become an integral part
of the diagnosis and outcome.”
“CME and CCE would in many ways
become one and the same.”
Which brings us to the third database, one that I envision will be called
Continuing Consumer Education (CCE). As the consumer movement
continues to evolve from educational empowerment to active engagement and
inclusion in the healthcare team, patients and their families will demand access
to the same hand-held hardware and information software that the other care
team members are using. This will help avoid any confusion that might arise
from multi-tracked information and accelerate the need for simple and welldesigned educational and organizational products.
Bridging the Translation Gaps
As CRD, CME, and CCE become widely accessible, we are left with two
translation gaps between new medical discoveries and those discoveries being
translated into practice. The first gap is between CRD and CME. For example,
if a study reveals that it is safer and more effective for the mother and the
child if the mother is given an epidural anesthesia at 2 cm rather than at 5
cm dilation, and that doing so not only does not increase C-section rates but
ensures safer, more comfortable labor and better Apgar scores for the baby,
under our past system, this knowledge transfer to practice would take many
years. However, with integrated CRD and CME databases, practice behavior
changes would become coincident with a new discovery.
“Do people not loan these data to the
people in whom they have the greatest
trust and confidence?”
If CRD and CME were to collapse upon each other, CME and CCE would in
many ways become one and the same. Over the past decade patients and their
caregivers have been gaining expertise and experience with new information
technologies and applications at roughly the same rate. Yet the movements to
organize an individual’s health data electronically was originally conceived as a
provider controlled function. The EMR was viewed as a hospital and officebased platform. The EMR concept has more recently broadened into the PHR,
a patient-centric organizing framework. But are separate approaches defensible?
Are these records not, after all, one and the same? Do not all clinical data
originate with the people? Do people not loan these data to the people in
whom they have the greatest trust and confidence: their physicians, nurses, and
other caregivers? Moreover, if our records are one and the same, should we not
also use the same informational resources to support our joint decision making?
Wouldn’t this method be the best way to help us stay on the same page and
avoid miscalculations, misinformation, or mistakes?
“Lack of adherence means
costly re‑treatment, and often
hospitalization, when conditions
The elimination of the translation gap between CME and CCE has enormous
economic implications also. Studies indicate that patients adhere to the plans
they establish with their physicians only 25 percent to 50 percent of the time.
Lack of adherence means costly re-treatment, and often hospitalization, when
conditions predictably worsen. In addition, many of the safety issues that
have been the focus of attention in the healthcare community in recent years
are based on miscommunication between healthcare providers and between
patients and their caregivers.
predictably worsen.”
Finally, the emergence of Clinical Effectiveness Research and the culture of
continuous process improvement are dependent upon evidence-based protocols
and processes shared and managed by patients and their clinicians. Together,
these trends carry with them the promise to transform our health delivery
system and to improve quality and efficiency simultaneously. Common shared
databases, used effectively in real-time and customized to patient need, are
critical to improving healthcare.
Vision 5: Techmanity — Technology as a Humanizing
Force
Back in 1983, Dr. John A. Benson, Jr., then President of the Board of Internal
Medicine, voiced these words when questioned about technology’s impact
on the patient-physician relationship. “There is a groundswell in American
medicine, this desire to encourage more ethical and humanistic concerns in
physicians. After the technological progress that medicine made in the 60’s and
70’s, this is a swing of the pendulum back to the fact that we are doctors, and
that we can do a lot better than we are doing now.” He accurately described the
mood of clinicians then, and for most of the 20th century, toward technology;
that is, a complex love-hate relationship. While they have rejoiced and cheered
on progress, they have struggled to accept and master change in a manner that
would avoid driving a wedge between them and their patients.
“Common shared databases are
critical to improving healthcare.”
Medical Informatics Meets Consumers
It is fair to say that, as the health consumer movement has matured over
the past 30 years, and physicians have moved away from paternalism to
partnerships and team-based approaches to care, that outright resistance and
abject fear of technology has subsided, and clinicians have progressed to and
beyond grudging acceptance. People and their caregivers have developed
computer skills together, pursued broadband and wireless connectivity
together, and discovered the value of personalized and customized computer
search engines together.
Alongside this evolution, the specialty of Medical Informatics has risen to
legitimacy within the medical hierarchy, and its leaders have reinforced the
need to take advantage of technology and informatics in support of humanistic
care. One such voice is that of Warner V. Slack, who heads the Center for
Clinical Computing at Harvard Medical School. His first published paper on
Medical Computing appeared in the New England Journal of Medicine in 1966.
His book, Cybermedicine: How Computing Empowers Doctors and Patients for
Better Health Care, is considered a classic, and argues, as Health Informatics
expert Kevin Kawamoto, from the University of Washington has said,
“Computers can be mutually beneficial for both the patient and the healthcare
provider.”
“People and their caregivers have
developed computer skills together.”
“In embracing technology in medicine,
we must view it as both assistive and
transformational.”
If we have managed to move as caregivers from resistance to acceptance of
technology in healthcare, I would suggest we have not moved far enough. As
I stated in a reference paper as chair of the technology sub-committee for the
National Commission for Quality Long Term Care: “In embracing technology
in medicine, we must view it as both assistive and transformational.”
Powering Up The Vision
“Our vision must be sufficiently
forward looking and expansive to
challenge technology innovators.”
The revolutionary strength of modern information and scientific technologies
is that they ignore geography. In so doing they allow us to reorient and
connect beyond the limits of a range of barriers whether they be physical,
social, financial, or political. The danger is not in over-reaching but in underreaching. Our vision must be sufficiently forward looking and expansive to
challenge technology innovators. Where are the “killer applications” that would
allow lifespan planning to move us ahead of the disease curve? How can we
target technologic advances in healthcare to first reach our citizens most at
risk? How do we, in powering the health technology revolution, broaden our
social contract to include universal health insurance? How do we unite the
technology, entertainment, and financial sectors (previously locked out of the
healthcare space) with the traditional healthcare power players, and incentivize
them to work together to create a truly preventive and holistic health delivery
system that is equitable, just, efficient, and uniformly reliable? How can each
citizen play a role in ongoing research and innovation, and help define lifelong
learning and behavioral modification as part of good citizenship? What can
corporate America do to advance the health information infrastructure, and in
“doing good,” do well financially, thereby serving Main Street as it serves Wall
Street?
Moving Beyond Acceptance
“Health Information leaders of
Health Information leaders of the 21st century need to be more revolutionary.
Were they to perform at their full capacity, our healthcare system would
be transformed. Healthcare would be oriented around relationship-based
care, cementing the people to the people caring for the people. If such
a transformation were to take place, we would see improvement on ten
different fronts simultaneously: access, efficiency, team-care coordination,
multi-generational family linkages, inclusion of informal family caregivers
in healthcare teams, targeted interventions for vulnerable populations,
informed mutual decision making, lifespan health planning, evidenced-based
personalized care, and a palpable presence of physicians, nurses, and care team
members in the home.
the 21st century need to be more
revolutionary.”
Further Reading
Kawamoto K. “Computer Technology in Health Care Settings.” The Journal of
Education, Community, and Values. May-June, 2003.
Magee M. Home-Centered Health Care: The Populist Transformation of the
American Health Care System. Spencer Books. NY, NY. 2007. Available at
www.spencerbooks.com.
Magee M. “Connecting Healthy Homes to a Preventative Healthcare System:
Leveraging Technology For All It Is Worth.” Harvard Health Policy Review. Fall,
2007, pp. 44-52. Available at http://www.hcs.harvard.edu.
Magee M. “Health Records of The Future.” Health Politics. November 18,
2006.
Nelson, B. “Can Doctors Learn Warmth?” New York Times. September 13,
1983. Available at query.nytimes.com.
Slack, Warren V. Bibliography. Harvard Medical School. Beth Israel Deaconess
Medical Center: Center for Clinical Computing. February 13, 2008.
Author Biography
Mike Magee, MD, is Editor of HealthCommentary.org. He is a Senior
Fellow in Health Policy at the Center For Aging Services Technologies and a
Commissioner of the National Commission for Quality Long Term Care. He
is a widely recognized public speaker and author of ten books including Positive
Leadership, Health Politics: Power, Populism and Health, and Home Centered
Health Care: The Populist Transformation of the American Health Care System.
He can be reached at www.mikemagee.org.
Copyright
Intel, the Intel logo, and Intel Atom are trademarks of Intel Corporation in the U.S. and other
countries.
*Other names and brands may be claimed as the property of others..
From People to Prototypes and Products: Ethnographic
Liquidity and the Intel Global Aging Experience Study
Contributors
Tim Plowman
Intel Corporation
David Prendergast
Intel Corporation
Simon Roberts
Intel Corporation
Index Words
Ethnography
Aging
Product Development
Ethnographic Liquidity
Healthcare
Abstract
This article documents how a large-scale, multi-site, ethnographic research
project into aging populations, the Global Aging Experience Study, led to
the development of concepts, product prototypes, and products for the
independent living market. Successfully leveraging the output of ethnographic
research within large organizations and product groups is often fraught with
challenges. Ethnographic research produced within an industry context can
be difficult for an organization to thoroughly capitalize on. However, careful
research design and sound knowledge transfer activities can produce highly
successful outcomes that can be thoroughly absorbed into an organization,
and the data can lend itself to re-analysis. Our research was conducted by the
Product Research and Innovation Team in the Intel Digital Health Group,
and the work was done in Europe and East Asia, eight countries in all. Using
a mixed methodology, our research examined health and healthcare systems in
order to chart the macro landscape of care provision and delivery. However,
the core of our study was ethnographic research with older people, and their
formal (clinical) and informal (family and friends) caregivers in their own
homes and communities. Data from this study were organized and analyzed to
produce a variety of tools that provide insight into the market for consumption
by teams within the Digital Health Group. As the results of the research
were driven into the Digital Health Group and other groups within Intel, it
became clear that the Global Aging Experience Study possessed what we term
ethnographic liquidity, meaning that the data, tools, and insights developed in
the study have layers of utility, a long shelf life, and lend themselves to repeated
and consistent use within and beyond the Digital Health Group.
20 | From People to Prototypes and Products: Ethnographic Liquidity and the Intel Global Aging Experience Study
Introduction
In 2006, researchers within the product research and innovation team within
the Digital Health Group launched the Global Aging Experience Study. This
is a multi-year, multi-site, ethnographic, research project designed to develop
a global, comparative understanding of the practices and meanings associated
with growing older. To date, we have conducted intensive, qualitative research
into older people, living in eighty-five households in eight countries. These
data, supplemented by additional interviews with dozens of informal caregivers
and healthcare professionals, resulted in a detailed database comprising field
and analytic notes, thousands of photographs, and five hundred hours of video.
Long-range research design, innovative reporting, and knowledge transfer
activities by the team have resulted in the data and analysis providing ongoing
value. In this article, we explore how this research has affected how we imagine
the new independent living technologies of the future.
“We explore how this research has
affected how we imagine the new
independent living technologies of the
future.”
Demography: the Age Wave and its Implications
The world’s population is growing older. According to the latest United
Nations biennial population forecasts, 11 percent of the world’s current
population of 6.9 billion are over 60 years old. By 2050, this will be 22 percent
of a total population of 9 billion people. However, the developed world will
be older, with 33 percent of its population over the age of sixty [1]. There are
two key demographic drivers of this change: longer life expectancy and lower
fertility rates.
People are now living longer lives and, in general, are healthier and more
active. During the course of the twentieth century, average life expectancy
within the developed world rose from 50 to 78 years [2]. Populations have
benefited from better basic healthcare and from the decline in infectious
diseases. However, fertility rates have continued to fall in the developed world.
The rate is now 1.6, which is below the 2.1 rate, regarded by demographers as
the requirement for a population to replace itself. This low fertility rate will
mean that global population growth will level out during the middle of the
century. However, it also means that the ratio of people who work versus those
who do not work, the dependency ratio, will continue to fall. For example, in
Britain in the early 1900s when old-age pensions were introduced, there were
22 people of working age for every retired person. In 2024, there will be less
than three [3]. Such a ratio has fiscal implications: governments will get less
revenue to support the health and social care needs of their aging populations,
and they will be less able to meet the pension entitlements and expectations of
retired people. Political and policy discourse around the inevitable bankruptcy
of the social security system in the United States is perhaps the most familiar
manifestation of the impending problem to U.S. residents.
“The developed world will be older,
with 33 percent of its population over
the age of sixty.”
“Governments will get less revenue
to support the health and social care
needs of their aging populations.”
From People to Prototypes and Products: Ethnographic Liquidity and the Intel Global Aging Experience Study | 21
Percentage of population over 65 years old,
2006
2050 Projection
2003 and 2004
2050 Projection
12.5%
USA
20.6%
3.35%
7.3%
19.7%
Italy
35.5%
4.87%
The ways in which different countries’ populations will age in light of the
demographic shifts just described are likely to differ widely, both from a
sociocultural and a material perspective. For example, in the United States, the
shift will be amplified by the aging and retirement of the so-called baby boomer
generation; i.e., the 80 million people born between 1945 and 1965. In Italy,
Spain, and Germany, the continued decline of fertility rates is resulting in
smaller families, which itself results in these countries’ populations growing
older, faster. But whatever the structural constraints (i.e., social, demographic,
cultural, or economic) on the aging experience, the anticipated challenges
presented by aging, both to the individual and societies, will be profound. See
Figure 1 for the percentage of populations in the developed world who are over
65 and 80, respectively, and also projections of aging as a percentage for those
populations.
15.2%
Looking at the 27 member states of the European Union alone, the rate at
which Europe’s population is aging relative to the number of younger people
available to provide support for elders is predicted to diverge. While the falling
dependency ratio is also due to falling fertility rates, the net outcome is that a
shrinking workforce threatens the fiscal base of numerous healthcare systems.
11.6%
Ireland
25.9%
2.65%
7.6%
17.6%
Sweden
24.7%
5.32%
9.7%
19.4%
Germany
28.4%
4.24%
12.2%
17.7%
Spain
34.1%
4.22%
12.3%
16.4%
France
27.1%
4.28%
10.9%
15.8%
UK
23.2%
4.32%
8.8%
0%
10%
20%
30%
40%
As the broad demographic picture changes globally, the health landscape
is being transformed. The decline of deaths due to infectious disease is
accompanied by the rise in the number of people with chronic diseases,
conditions increasingly associated with affluent and sedentary lifestyles. Among
these chronic diseases are, for example, Type 2 diabetes, chronic obstructive
pulmonary disease (COPD), and congestive heart failure (CHF). These diseases
are expensive to manage and represent a significant strain on the healthcare
systems of the developed world. Annual U.S. costs of COPD were $37.2
billion in 2004, which included $20.9 billion in direct healthcare costs, $7.4
billion in indirect morbidity costs, and $8.9 billion in indirect mortality costs
(from the American Lung Association). However, many of the developing
nations are experiencing significant increases in the incidences of such diseases
also. It is also important to note that individuals with these conditions are
not the only impacted parties: caregivers, public health systems, payers, and
employers are also negatively affected by the rise in the incidences of these
diseases.
Figure 1: Percentage of Population Over 65, and
Over 80, and Projections
Health and Welfare Systems
“Of critical interest to our research
While differences exist in the ways that countries will age, there are also
significant variations in the ways that countries are organized to respond to
the challenges and opportunities that an aging population present. Of critical
interest to our research team was the ways such systems have evolved — how
they are funded and structured — and how people comprehend, experience,
and behave in relationship to these systems. A base assumption of the project
was that there is a dynamic relationship between health and care systems and
the ways people think about, and respond to, health challenges and the process
of aging in general.
team was the ways such systems have
evolved.”
Spain, Sweden, and Italy appear to receive comparatively high dividends for
their levels of investment in healthcare; i.e., the overall measures of national
health relative to the percentage of GDP spent suggests that those euros are
well spent. This suggests that cultural, environmental, and other factors are at
least as important as formal healthcare systems in shaping health outcomes.
However, it is worth remembering also that a high proportion of healthcare
expenditure is directed towards treating ill-health, particularly for those over
the age of 75 [4].
For example, in Europe there is considerable diversity in the ways that welfare
states are organized and how health and social care for older people are
delivered. A range of factors underpin this variety: the historical development
of welfare states; local, regional, and national ideas about the role of the state
versus the individual, family or third-sector (voluntary) in providing care; and
the fiscal and economic frameworks in which development has occurred within
these countries. The interplay between people, practices, policy and politics,
and economics has created a complex and mutable health and healthcare
landscape.
Analysts have created a series of models that seek to describe and categorize
the different welfare systems of Europe. These models provide a good guide
to understanding the fundamental principles or structure of how care is
organized and financed. Notably, Esping-Anderson’s [5] work identified
three distinct social welfare regimes. These are the social democratic model
(Nordic countries), conservative or state corporatist model (Germany or
the Netherlands), and the liberal welfare or Anglo-Saxon model (United
Kingdom). Ferrera [6] subsequently added a fourth category — the Southern
European model including Italy, Greece, Spain, and Portugal. In the United
States, the system can best be characterized as a liberal, capitalist model that
“endorses equality of opportunity but not of outcomes” and is arguably
outperformed by the state corporatist model in terms of social and economic
objectives [7].
“The interplay between people,
practices, policy and politics, and
economics has created a complex
and mutable health and healthcare
landscape.”
“These models provide a good guide
to understanding the fundamental
principles or structure of how care is
organized and financed.”
“In short, these models render human
and economic activity in brush
strokes too broad to support nuanced
insights.”
“This shift towards a more
community- and home-centered
approach to care is being forged, with
varying degrees of success, through
attempts to create the optimal mix
of funding and provision of care by
citizens, family, state, and private and
voluntary sectors of society.”
These models represent high-level views of systems and so fail to capture the
regional and local variations in delivery that often makes care provision deviate
from these ideal, typical models. In short, these models render human and
economic activity in brush strokes too broad to support nuanced insights into
phenomena such as the relationship between policy and the experience of aging
in a given socio-economic structure. Over recent years and in anticipation of
dramatic transitions within the demographic landscapes of Europe, there have
been significant changes in policy planning and rhetoric surrounding how
welfare and care systems operate. European long-term care systems demonstrate
that different attitudes and expectations exist about the relative roles of family,
state, and volunteers.
To answer the questions of shifting demographics and varying approaches
to healthcare, many countries are moving away from hegemonic, expensive,
institutional, and medicalized responses towards a more community- and
home-centered approach to care. The propensity of bio-medicine to extend its
domain over a range of real and perceived maladies, despite any empirical basis
for doing so, has been well documented within the social science literature.
Scheper-Hughes and Lock [8] argue that “the funnelling of diffuse but real
complaints into the idiom of sickness has led to the problem of medicalization
and to the overproduction of illness in contemporary advanced industrial
societies.” In addition to the gradual bankrupting of healthcare systems, owing
to shifting workforce ratios, medicalization has also contributed to healthcare
systems being overburdened and dysfunctional, as well as to inadequate
institutional and social responses to the challenge of aging. This shift towards
a more community- and home-centered approach to care is being forged,
with varying degrees of success, through attempts to create the optimal mix
of funding and provision of care by citizens, family, state, and private and
voluntary sectors of society. This multi-faceted approach frequently entails a
repositioning of the state as a financier, rather than as a direct provider of care
to individuals, through the amplified use of market mechanisms, the growth
of the private and commercial care industries, and increased regulation and
funding of the not-for-profit and voluntary sector [9]. Additionally, a central
component of the rethinking that is underway in the way that care for older
people is organized is a commitment to home-based models of care in which
technology plays an enabling role.
The Intel Global Aging Experience Study
The need for innovation today in order to prepare for tomorrow’s demographic
change was the primary context in which the Global Aging Experience
Study was conceived and conducted. The work was designed to support the
Digital Health Group’s commitment to affecting a paradigm shift within
the independent living market. Our research built on a foundation of
earlier work conducted in the United States, and we sought to extend that
work into Europe and East Asia thereby providing concrete local detail,
while simultaneously developing a more thorough global perspective on the
experience of aging. In addition to deepening our understanding of the myriad
social and cultural differences in people’s subjective experiences of aging and
health, our other research objectives were to challenge prevailing assumptions
about what it means to grow old and to identify strategic opportunities
for appropriate technologies and services for older people. Grounded in a
thorough review of the gerontological literature, and utilizing ethnographic
techniques such as open-ended interviews, observations, and multi-day
visits at multiple households in each country, our team gathered thousands
of images, stories, and insights about what it means to grow old from the
perspective of older people themselves. This was the first step in a long process
of understanding the needs over time for real people. Local researchers and
healthcare professionals helped us recruit older people from diverse socioeconomic backgrounds and with a wide range of health conditions. Efforts
were also made to ensure a reasonable distribution of ages was represented,
ranging from 60 to 100 years old. Researchers would typically spend two days
per household. The first day was usually spent getting to know the occupants
and exploring their life and health histories, while the second visit involved an
exploration of the home and the meaning and use of material objects within
it. The ethnographic interview ended with a mapping exercise and frequently,
it ended with trips around the neighborhood with the senior to meet their
friends, families, and community members. Our style of questioning was
purposively fluid and relaxed, providing encouragement and time for
participants to think through and formulate their responses, often revisiting
sensitive or painful memories. Over the course of the ethnographic encounter
the following domains, among others, were gradually probed and explored:
•• Older people’s relatives, acquaintances, and care networks.
“The work was designed to support the
Digital Health Group’s commitment
to affecting a paradigm shift within
the independent living market.”
•• Life review and biography.
“Our team gathered thousands of
•• Experiences and expectations of aging.
images, stories, and insights about
•• Health and housing histories.
what it means to grow old from the
•• Older people’s relationships with their built, material, and social
environments.
perspective of older people themselves.”
•• Perceived and actual availability of formal and informal support networks
following critical health events or along chronic disease pathways.
•• Health information sources used by older people and their carers in
different parts of the world to make informed decisions about both their
treatment and their future.
•• Everyday life, technology, and home.
We provide a vignette to demonstrate the wealth of material and insights that
can be gained from just one of these case studies.
Widowhood and Aging in an Italian Village
“Anna brought up her own children
to work hard and be financially
independent.”
Anna (85) shares a house with her unmarried oldest son Dario in a village
about an hour from Milan. She has lived in this area all her life and soberly
recalls the poverty of her youth. “I remember a widow came to my mother
and told her that her children didn’t want to sleep because they were hungry.
And my mother gave her some flour...” Anna developed an abhorrence of debt
after seeing her father, a seed tradesman, in difficulties, and she brought up her
own children to work hard and be financially independent. Life wasn’t easy. To
make a profit from the small café bar she and her husband ran demanded their
attention eighteen hours a day. When her husband suddenly died from acute
kidney failure in 1973, she managed to close their business for eight days and
then the family had to go on working. Times were hard, but they were able to
survive, as her three children were already working. Now well into her eighties,
Anna reflects how she feels differently inside in comparison to how she felt in
her youth, “I am different in the way life is different now. In the past I had to
sacrifice a lot. I managed to get a house to pass onto my children. I worked
hard for it. My husband liked to have a motorcycle but work was secondary for
him. It was always first with me.”
As she ages, Anna feels she has a safety net in her children and especially
her oldest son who has taken on the role of family caregiver. Italian law
stipulates that an elderly parent in need has the legal right to demand either
accommodation or financial help from children with resources. Many would
not press this right however. Anna’s daughter now lives in another part of Italy
and so can only visit for holidays, but they talk a great deal on the telephone.
“As things stand today, young Italians
entering the workforce will have to
pay contributions equivalent to 127
percent cumulatively of their salaries
over the next fifteen years to guarantee
the same level of benefit.”
Anna believes older Italians, though still reliant on the family, live better today
than in the past due to the basic state pension — a welfare benefit the country
may have trouble supporting for future generations. As things stand today,
young Italians entering the workforce will have to pay contributions equivalent
to 127 percent cumulatively of their salaries over the next fifteen years to
guarantee the same level of benefit support received by the current older
generation. Anna is able to subsidise her income a little with a small pension
from the days when her husband worked in a factory, but aside from this, like
many women and small business owners, she regrets they were not able to
contribute to personal pensions.
Anna feels her health has seriously started to decline over the last year with
recurrent problems with her knees causing her the greatest concern. In 2002,
her arthritis was causing her so much pain she opted for a knee prosthesis
operation against her doctor’s advice. She was in hospital for three weeks and
then had to spend six weeks at home in bed being cared for by her son and
sister. Her treatment included an hour of physiotherapy per day and a passive
exercise machine to prevent her muscles from atrophying. Her rehabilitation
was paid for by the healthcare system for two months and she feels this was
not long enough. She neglected her exercises, and now problems have begun
to emerge with her other knee due to long periods of over compensation. This
is partly because she felt it demeaning to use a walker in public and preferred a
single walking stick.
“She felt it demeaning to use a walker
Anna suggests the chronic pain in her legs is helped by massage and creams.
Unfortunately she is unable to get massages on the public health service and
private practitioners charge €40 an hour, a sum she feels guilty about spending.
Anna feels alienated from her doctor so she avoids visiting her local clinic. Her
shoulder has been troubling her recently and when she asked for more of the
cream that works on her knee to fix the problem, he refused on grounds of
expense. Nowadays, Anna just phones in when she needs her prescription and
her son picks it up. She finds it very irritating that she has to do this every six
to twelve days, as she is only allowed one box of twelve blood pressure pills at a
time and would like more pills in each box to save her the trip.
“Anna feels alienated from her doctor
Decreasing mobility is having a significant effect on her quality of life. “I feel
old because I am dependent on other people. The problems with my legs make
me feel old. I don’t have any plans for the future now. I don’t want to go out
dancing but I would love to visit a specialist to be able to move around better.”
For the last eight weeks, Anna has not left her apartment. Instead she spends
her days watching the world go by from her balcony and trying to do the little
she can in terms of housework: her family decided to pay for a home help
worker to visit four hours a week to clean. Her son has taken over the shopping
duties. Anna is not able to conceive of using an electric buggy to get around
as she no longer believes she is safe going out by herself. Having given up on
travel, she now regrets not seeing more of the world during her life. The main
variation in routine occurs when her daughter or sister comes to help look after
her once a year when Dario takes a respite break from his care-giving duties
and visits a health spa. “I would consider a nursing home during these times,
but only for a month, for a change, never for good.”
Anna uses sticks to get around and has a stick located in every strategic position
in the household. She sometimes tests and pushes herself by attempting to walk
between resting points. The main obstacle for her in the house is the slippery
marble staircase from her apartment down to the ground floor.
in public and preferred a single
walking stick.”
so she avoids visiting her local clinic.”
“For the last eight weeks, Anna has
not left her apartment. Instead she
spends her days watching the world go
by from her balcony.”
“As Anna’s mobility has declined and
her social circle has narrowed, her
phone has become an increasingly
important lifeline.”
Anna has heard of alarm pendants but does not have one. She carries a mobile
phone with her in case of emergencies but never takes it into the bathroom
with her, one of the most dangerous rooms in the house. Last year, Anna had
a fall in her bedroom and could not get up. Her son was not able to hear her
cries over the living room TV and her mobile phone battery was flat. She
managed to crawl to her charger but didn’t realize that she could use the phone
while it was plugged in. It was two hours before she was discovered.
As Anna’s mobility has declined and her social circle has narrowed, her phone
has become an increasingly important lifeline. Her son works long hours, and
she receives few visitors: she, therefore, calls her sister as often as she can afford
it. She can still cook a little and loves to sew. She used to make clothes for
her family, but she has stopped as nobody wears what she makes. Reading is
another hobby, as is listening to the radio. The real highlight of her month is a
visit from her grandchild. This occurs only rarely, however, as she dislikes her
second son’s wife and they do not feel she is capable of taking care of the child
on her own. “I don’t think I would want to spend another twenty years living
like this, though I would love to see my grandchild married. Although I am
alone a lot, I am not lonely. I can always watch the street from my balcony.”
“The real highlight of her month is a
visit from her grandchild.”
Developing Insights and Tools for Knowledge Transfer
As the selected field notes of the interview with Anna demonstrate,
ethnographic fieldwork requires a balance between having an appropriate focus,
but not being so focused on one topic that you lose sight of what is important
to the participants themselves. Ethnography, in this respect, is not like
requirements gathering, usage model development, or design research, where
the goal is to determine the boundary conditions for a particular product.
Instead, we are trying to understand what it is that people want and need
through a holistic exploration of their subjective experience, and the associated
meanings and behaviors that interpellate [10] with wider socio-economic
structures. The requirements come later.
When ethnographers return to the office, they bring with them images, audio
recordings, video recordings, and hundreds of pages of field and analytic notes
to both review and log for later analysis. As depicted in Figure 2, transcribed
voice recordings and field notes are then entered into qualitative data analysis
software to be coded into themed categories that allow for a horizontal view
across the data set to be developed.
“We are trying to understand what
it is that people want and need
through a holistic exploration of their
subjective experience.”
Figure 2: Qualitative Software for Coding Raw and Analytic Field Notes
As important as systematic coding of interviews are, group analytic working
sessions, or harvest sessions, are equally important. Harvest sessions are where
data from the field, the photos, and other collateral are shared, in an attempt to
inductively identify patterns in the data, as well as to note the important
dimensions of variability within and between countries. These tasks are
accomplished by working through the data and actively listening for recurring
insights, themes, and other aspects of the data. This kind of analysis requires
very active participation and constant critical engagement. Post-it notes are
used to capture ideas as they emerge. After hours, sometimes days, of sharing
stories from the field, the team begins to organize what might be hundreds of
post-it notes into clusters, and robust patterns begin to appear.
Identification of the patterns in the data leads to grounded theory insights about
what is most important to people. For instance, one persistent idea that came
up in story after story in our Global Aging project was simply this: people don’t
want to be treated as if they are no longer competent or valued members of
society. They are human beings, with aspirations, goals, and a sense of identity
and self-worth. And yet, so many healthcare devices and services treat older
people as if they were children, or worse.
“This kind of analysis requires very
active participation and constant
critical engagement.”
“This kind of analysis requires very
active participation and constant
critical engagement.”
U
U
N
TI
N
Supporting cognition
“You have to challenge
your mind and brain.”
M
IN
D
-B
O
DY
C
O
Feeling safe
“Since I fell I’m a lot more
afraid of falling.”
M
TH
E
Environments
of choice
“Despite my lack of mobility
I can turn on garden lights
with this remote control.”
Bringing
healthcare home
“People think that doctors
can cure everything—
that’s not ture.”
Meaningful &
useful life
“It would be great to maybe
have an exhibition of my
work sometime.”
Enabling
social interaction
“I don’t like to be alone.”
Supporting
physical activities
“I want to move easily,
be independent.”
Help
getting care
“We know the pharmacist
very well, it’s easy to get
my medicine.”
Figure 3: Initial and Final Versions of an Opportunity Map
As more and more of these needs are noted, the team begins to cluster them
into what we call the opportunity map. The map, featured in Figure 3, helps us
organize many of the possible ideas about needs and technology ideas that
come up during sharing of field stories, or ideas about services or other
interventions. We repeatedly refer to this map when thinking about products
already on the market, or products in development within the Digital Health
Group. By doing this we can identify gaps or places that need more attention.
Beyond the identification of needs and opportunities, when thinking through
the ethnographic data, the study team identifies insights that are neither ideas
for new products nor areas of explicit need; rather, they are insights into the
required characteristics of any device or solution we might develop. We capture
these as design principles (see Figure 4).
Figure 4: Design Principles Derived During the
Analytic Process
With all these materials and insights in hand, we finally have a basis for
actually thinking about products, services, or other interventions. We follow up
harvest sessions with design brainstorms. During these work sessions (see
Figure 5), we use the opportunity maps to identify which slice of the map we
want to address. Keeping in mind the values and design principles from our
data, we begin to explore ways of addressing particular needs. Here is where
mapping other products, technologies, or research onto the map ahead of time
really helps inform our thinking.
Key Aging Experience Themes
A range of important themes emerged from the analysis of the Global Aging
Experience data set. Seven of these are outlined next.
People want to focus on what they CAN do, not what they CAN’T do
As one woman told us, succinctly and unambiguously, “You are sick when you
are lying in bed.” That is why so few people self-identify as either ill or old.
Many people chose not to use canes or assistive devices in the home. This is not
just because these devices are socially stigmatizing in appearance, but because
these devices reinforce a personal identity as someone who is sick. Many people
sought out challenges as ways of keeping themselves sharp: in fact it seemed
that it was people’s energy level, their will to pursue such challenges, that
most correlated with self-identification as ill or old. Still, we cannot avoid the
fact that many people will and do need assistance. The key is to provide this
assistance in ways that people recognize “as helping me do what I want to do,”
not as a constant reminder that I am no longer capable.
Figure 5: GAE Brainstorming Session
“Many people chose not to use canes or
assistive devices in the home.”
We identified a sort of denial that is a healthy part of the natural aging process
that makes some interventions very difficult. We call this adaptive optimism.
Often, people will regard most interventions as not necessary until it is too late,
unless we can find a way to introduce these interventions into their lives earlier.
The clear implication of this is that we need to be thinking about technologies
that adapt and age with a person, changing the mix of offerings as the person
ages.
“Often, people will regard most
interventions as not necessary until it
is too late.”
“These factors can seriously impact
a person’s ability to live the life they
desire in later years.”
Healthy aging and independent living mean far more than health
There are many factors that enable a person to remain at home and relatively
independent. These include a wide variety of capabilities, not just health-related
ones. The ability to take care of one’s own home maintenance or gardening, the
ability to get groceries, prepare meals, and clean up afterwards, the ability to
get around the neighborhood or town, are among some of the most important
ones. All of these factors can seriously impact a person’s ability to live the life
they desire in later years. We need to be thinking about all of these factors
when we design interventions. A few of the key areas for enabling services are
these:
•• Mobility and transportation in the community are crucial. Communitybased transportation initiatives are catching fire both in the United States
and in Europe. Different attitudes towards private transportation and
different availability of public transportation will mean very different
systems in different places.
•• Services for the home are becoming increasingly important. This is
particularly true for widowed husbands or wives: the loss of a spouse can
mean a serious adjustment of lifestyle, at a time when the ability to adapt
is not what it once was. Cooking, cleaning, home maintenance, and other
forms of routine care will become increasingly needed. An opportunity
exists to provide an infrastructure to enable a broader, less centralized
marketplace for trusted providers.
•• The need for finding trustworthy providers is going to increase. Technology
can play a major role in helping communities identify and enable trusted
providers. This may be particularly important considering that some forms
of care that one would expect to come from family members will come
from strangers.
Health is not an objective quality; it is defined collaboratively and culturally
Health is defined through interactions and negotiations among various people,
including informal caregivers, family members, hired in-home caregivers,
and medical caregivers. We saw many differences within and between these
networks in our assessments of an elder’s health.
•• Assessments of health can vary from person to person. In Germany, for
instance, an elderly husband insisted that his wife (who had suffered a
mild stroke) needed much more help with driving, shopping, and taking
her medications than the woman herself felt she needed. Both she and her
daughter felt that the husband was being overly protective. In multiple
cases, children had put their parents in nursing homes even though
those parents did not feel they needed to be there. And yet, the parents
acquiesced, mostly because they “did not want to be a burden.”
•• Notions of health vary from place to place in both major and minor ways.
The cultural, social, and political systems in which we are embedded shape
our attitudes and behaviors with regards to health. In England, people
behave in particular ways as a result of the presence of the National Health
System’s guarantee of life-long, free healthcare. In Mediterranean countries,
people do not recognize eating as a health-related practice. They simply eat
what people outside the region recognize to be very healthy foods.
People mark the progression of aging by watershed events
People do not experience aging as a gradual loss of capability, but rather as
a series of threshold events. It is most obvious in the case of falls, where a
combination of physical or cognitive decline might go unacknowledged for
a long time before the precipitating event, namely, the fall, makes it official.
While the obvious solution might seem to be monitoring and intervening
earlier, we suggest it is not that simple: people who are in this state of adaptive
optimism or denial might not willingly submit themselves to this kind of
intervention.
•• Some watershed events initiate decline. Non-health-related events can have
a serious health impact. For example, the loss of a loved one or a child,
resulting in grief and depression, may have measurable, negative health
consequences.
•• Sometimes external events leave deficits that expose health decline. The
loss of a spouse may entail the loss of a person who has for years helped
one cope with other deficits. A wife who has prepared her husband’s meals,
done his laundry, and helped with other daily life needs over a period of
forty or fifty years will, upon death or disability, leave a huge gap deficit
that the husband or other informal caregivers will need to overcome.
“Meaning is made through social
interaction and that does not cease in
older age.”
Healthy aging is inextricably linked to social participation
People of all ages aspire to have a sense of belonging, a legitimate role in
the life of their family and community. We are meaning makers all through
life: meaning is made through social interaction and that does not cease in
older age. At the same time, people become more acutely aware that ongoing
engagement with the community or their family might actually increase their
sense of being a burden, not a contributor. Thus, enabling social participation
means lowering the costs associated with social engagement in at least three
ways:
•• Feeling useful or productive, or at least having something to offer and the
sense of identity that comes with that. This could be either in the form
of caring for grandkids or being able to tell one’s story, to put one’s life’s
history in context.
•• Enabling emotionally satisfying contact with the people the elderly care
about, people they share relations or a history with. At the same time, note
that there are costs associated with such social contact, and those costs
seem to rise with age (for example, as you lose your ability to drive, or
when cognitive impairments affect your ability to remember names on the
telephone).
•• Enabling recognition and lightweight engagement with a broader
community. As one of our participants told us, “Sometimes you just want
to look out your window and see what’s happening in your neighborhood.”
In many European communities people placed a lot of value on being
known in a place, of interacting with people with whom they share some
history or interests. This could come from such activities as going regularly
to the local market, or participating in a club.
“One interesting theme to emerge from
our work was a deeper discussion of
why nursing homes or institutional
residences were generally regarded as
bad, while staying at home is generally
regarded as good.”
The lived-in space is crucial to the experience of aging
People’s choice of objects to inhabit their homes, as well as less malleable
aspects of architecture, location, and other aspects of the physical environment
were important in how people experienced aging and health. One interesting
theme to emerge from our work was a deeper discussion of why nursing homes
or institutional residences were generally regarded as bad, while staying at home
is generally regarded as good. As we teased the attributes apart we realized that
these elements characterize differences across many kinds of environments,
including movement from one private residence to another. These elements
suggest interesting possibilities for technology:
•• Houses reflect cultural norms around physical privacy. There is a reason
why bathrooms are hidden in European and American homes. There are
cultural notions of privacy and intimacy associated with care and nurturing
of the body, particularly hygiene. We need to be cognizant of how different
cultural values around bodily intimacy may shape acceptance or resistance
to technologies.
•• Houses are the sites of spiritual and personal expression. Expressions of
spirituality and the emplacement of memories (for example, in shrines to
lost loved-ones) abounded in the houses we visited.
•• Enacting of micro-routines. Simple daily activities, from checking the
barometer, to drinking a glass of juice at bedtime (and using the empty glass
as a medication reminder in the morning) to gardening, were crucial for
people for multiple reasons simultaneously: as a way for people to fill little
slots of time, as a way of grounding behaviors in some structure that aids
memory, to provide some lightweight ways of finding meaning and having
something to talk about, get a little bit of physical exertion, keep one’s mind
sharp, and generally have some sense of small purpose to focus on each day.
•• The home is not just the four walls. It is the physical situation of the house
in the neighborhood, proximity to other services and opportunities for
social engagement. One woman we visited in a nursing facility in Spain was
quite happy there, partly because the home was in her old neighborhood,
near the same market, the same services, and the same social network that
she had always had.
Healthcare networks are large and increasingly complex just about everywhere
People in virtually every country we visited struggled to get the best value out
of their healthcare systems. People struggled with healthcare bureaucracy and
sought to bring alternative approaches to care into alignment:
•• Help people figure out their options. In places where coverage is universal,
people still seek out alternatives. In the United Kingdom, despite universal
coverage, people find it necessary to pursue alternative (private) healthcare
systems to speed up access. In some cases, people had to leave their country
to gain access to treatments that were unavailable because of resources or
regulations.
•• Help people help each other. Several people we visited had been forced to
learn a lot about the healthcare system, because of a chronic condition
or the need to care for someone who is ill. More than one noted that it
was unfortunate that, when their situation changed (a patient died or got
better) they had no place to share this hard-won knowledge. Simple tools
might make a collaborative user-based system to help people share that
knowledge and help each other.
The identification of key themes such as these provides broad insight into the
issues, problems, and desires of participants to help guide the development of
effective, culturally sensitive, and age-appropriate technologies. We now outline
some examples of how the global aging experience research program has
stimulated more in-depth studies and has contributed to the cycle of product
incubation and development, constantly ongoing within the Intel Digital
Health Group.
“Over the past decade, a somewhat
different style of ethnographic research
Ethnographic Liquidity
Since the beginning of the twentieth century, the vast majority of ethnographic
research has been conceived and consumed within an academic context. The
structure of ethnographies as academic texts, and the tools and techniques used
to produce them, are well fitted to an audience of scholars that, to a greater
or lesser degree, sees ethnographic research as cumulative and contributing
to anthropological and other related fields of inquiry. Over the past decade, a
somewhat different style of ethnographic research has been developed in the
context of industry and commerce. This work differs in scope and duration.
It does not bear the same implied scholarly and cumulative relationship to
academic ethnographic research.
Within the context of industry, ethnographic research has different demands
placed on it and different gauges are used to assess the relative success or
failure of an ethnographic project. A key demand placed on ethnographic
research in this new context is that of immediate relevance. Equally, multiple
stakeholders expect the research to be actionable. The term actionable refers
to the requirement that the research must be problem-directed and result in
an analysis that produces results that are easily consumed, understood, and
acted upon by other stakeholders in an enterprise (for example, research that
produces engineering requirements leading to product specifications).
has been developed in the context of
industry and commerce.”
“A key demand placed on ethnographic
research in this new context is that of
immediate relevance.”
For research to have an impact in any organization it needs to circulate so that
the findings can be understood, conclusions discussed, and the implications
fleshed out by relevant stakeholders. It could be argued that research that does
not travel through an organization can only ever have limited impact, since it
is on this journey that audiences can create for themselves a meaning for the
research. However, the impact of ethnographic research in the context of large
organizations, and beyond, can often be impaired by issues of circulation.
Creating outputs that travel well is all important to developing what we call
ethnographic liquidity, that is, the ability of research to be converted into
something of value by its audiences.
“If research activity and its output is
liquid, it is readily exchangeable.”
Therefore, another way of thinking about the actionability of ethnographic
research is through the lens of liquidity. If research activity and its output is
liquid, it is readily exchangeable. The research creates debate, is able to inform
existing activities, and creates the basis for new endeavors. Liquid research will
perform different functions for different members of an organization, because
it is multivalent and contains different layers of utility. For example, engineers
and designers might focus more on design principles as a means of guiding
their work. Marketing may take more note of needs and compelling ways of
telling their business story.
In short, the best ethnographic research in an industrial context is research that
has continued resonance and meaning. In essence, there are two competing
demands placed on ethnographic liquidity. First, the research must be
conceived and conducted to meet current organizational objectives. Second,
the research must have prolonged and ongoing relevance for the organization.
When we commenced the design of the Global Aging Experience Study, the
team was new to a recently created business division. The organization to
some degree was still, to borrow the concepts of Tuckman [11], storming and
forming. As a result, the research was conducted as much to shape the activities
of a business division as it was to meet a pre-defined set of research needs. An
explicit goal was to create a piece of liquid research that would endure and have
long-term value.
“The research was conducted as much
to shape the activities of a business
division as it was to meet a predefined set of research needs.”
The Global Aging Experience Study was designed accordingly. A foundation
of the research was an extensive review of gerontological literature and its
dominant theories of aging. This review lead to the creation of domains
of experience that were used to create the interview guides and the coding
system later applied to our data. While this grounded theory research approach
is commonplace in the academy, it is less so in industry. (Researchers and
management in industry generally perceive this approach as too academic and
too resource intensive. The members of the Digital Health Group, however,
viewed this approach as a wise, long-term investment). The domains we created
remain relevant to the aging experience and have enabled other researchers to
access and mine the original data we collected for other projects within the
Digital Health Group, a practice that will continue for the foreseeable future.
Another aspect of the ethnographic liquidity of our research is the multiple
artifacts we have created to disseminate the research. These include video,
PowerPoint* presentations, academic papers, printed internal and external
reports, press releases, conference talks, posters, and an opportunity map. Key
to this strategy of dissemination has been the production of materials in an
analog format.
We have focused on the production of high-quality, printed material in the
form of booklets. Booklets are used to draw together large projects presenting
ethnographic profiles, country overviews, and illumination of the analysis of
the material. The booklets aim to provide content that will become on-going
resources that diverse readers find useful (for example, by including relevant
statistics and demographic and market data). Our experience has been that
focusing on materializing research in this way has allowed us to increase the
liquidity of our work. Perhaps counter-intuitively, moving ethnographic
material out of digital formats into paper formats can make it easier to
circulate. Further, its existence in an organization becomes more durable.
Materials in this format have been crucial to supporting the persistence of our
research in the geographically dispersed, digital workplace. Furthermore, we
have found that producing versions of our documents [12, 13] for external
audiences further enhances the liquidity and durability of the original research.
“Booklets are used to draw together
large projects presenting ethnographic
profiles, country overviews, and
illumination of the analysis of the
material.”
Because of the ethnographic liquidity characterizing our work, the organization
has made repeated use of it. The following represents a sample of activities to
which the Global Aging Experience Study has contributed, either in part or in
whole:
•• Deeply informed the initial conceptualization and subsequent development
of two major product incubation efforts, one of which has developed into a
key program within the Digital Health Group.
•• Defined a further research agenda examining social health and social
participation in more detail within the context of the European Union and
the United States.
•• Resulted in the submission of 60 or more invention disclosures for the
Digital Health Group.
•• Informed major research efforts in the Technology Research for
Independent Living (TRIL) research partnership between Intel and the
Irish government within the areas of social connection, cognitive decline,
and falls. One specific example is how older people negotiate movement
through their homes and develop pathways in the household. This insight
informed the development of a sensor strategy.
•• Developed an operational blueprint for ethnographic research of this scale
and complexity and identified best practices for knowledge transfer.
•• Launched deeper research efforts in the areas of sleep and sociality,
transportation and mobility, social care, active retirement groups, and the
reinvention of retirement.
Figure 6: Front Covers of Two External-facing
Documents
Conclusion
In this article, we have discussed the Global Aging Experience Study in
the context of ethnographic liquidity and knowledge transfer. The project
afforded our team an opportunity to develop tools and artifacts that have
led to the continued relevance of our research to the Digital Health Group.
One can argue that conducting fieldwork and analyzing data represents the
comparatively easy parts of any research project. The real challenge when
conducting ethnographic research in the context of industry, comes in the
practice of sustained knowledge transfer and in the ability to drive the insights
gained and communicated through research into a program for development.
References
[1]
Beck, Barbara. “A Slow Burning fuse: A Special Report on Aging
Populations.” The Economist, June 27th, 2009, page 3.
[2]
Ibid.
[3]
“Aging population: Facts behind the fiction.” At news.bbc.co.uk
[4]
World Health Organization. At www.who.int
[5]
Esping-Anderson, Gøsta. 1990. The Three Worlds of Welfare Capitalism.
Princeton University Press.
[6]
Ferrera, Maurizio, ed. 2005. Welfare State Reform in Southern Europe:
Fighting Poverty and Social Exclusion in Greece, Italy, Spain and Portugal.
Routledge: New York.
[7]
Goodin, Robert E., Headey, Bruce, and Muffels, Ruud. 1999. The Real
Worlds of Welfare Capitalism. Cambridge University Press: Cambridge.
[8]
Scheper-Hughes, Nancy and Lock, Margaret. “The Mindful Body: A
Prolegomenon to Future Work in Medical Anthropology.” Medical
Anthropology Quarterly, Volume 12, Issue 3, 1987.
[9]
Timonen, Virpi, Doyle, Martha and Prendergast, David. No Place Like
Home: Domiciliary Care Services for Older People in Ireland. Liffey Press:
Dublin, Ireland, 2006.
[10] Althusser, Louis. 1969. For Marx. Translated by Ben Brewster. Verso:
London.
[11] Tuckman, Bruce. 1965. “Developmental sequence in small groups.”
Psychological Bulletin 63 (6): 384-99.
[12] Roberts, Simon and Prendergast, David. 2009. “Community Supports
for Aging: Care Pathways for Older People in Europe.” Digital Health
Group, Intel Corporation.
[13] Plowman, Tim, Roberts, Simon and Prendergast, David. 2007. “The
Global Aging Experience Project: Ethnographic Research.” Digital
Health Group, Intel Corporation.
Author Biographies
Tim Plowman, PhD, is a Senior Research Scientist and a Medical
Anthropologist for Product Development in the Digital Health Group at
Intel. He has been leading innovation from a social science perspective in
Silicon Valley for over a decade. His current work focuses on aging and
possible instrumental and non-instrumental applications of information and
communication technologies in support of successful aging. He holds multiple
patents and has published widely on social science, technology, and design. His
e-mail is tim.plowman at intel.com.
David Prendergast, PhD, is a Social Anthropologist in the Digital Health
Group at Intel and a Principal Investigator of the Social Connection Strand of
the Technology Research for Independent Living (TRIL) Centre. His research
focuses on later-life course transitions, and he has authored a number of
books and articles on aging and health. David utilises ethnographic research
to co-design and iteratively develop culturally appropriate, independent-living
technologies for older people. His e-mail is david.k.prendergast at intel.com.
Simon Roberts, PhD, leads the European social science and design team
for Product Research and Incubation in Europe and is the Intel Principal
Investigator on the ethnographic research strand of the TRIL Centre. He is an
Applied Anthropologist with over ten years of experience translating research
into product, service, and business opportunities. Simon has published widely
on ethnography, the application of anthropology, technology, design, and the
aging experience. His e-mail is simon.w.roberts at intel.com.
Copyright
countries.
Adapting Technology for Personal Healthcare
Contributors
Terrance (Terry) Dishongh
Intel Corporation
William (Bill) DeLeeuw
Intel Corporation
Mark Francis
Intel Corporation
Index Words
Sensors
Surveys
Social Care
Personal healthcare
Long-term Care
Abstract
The increase in the aging population in the United States, coupled with
healthcare costs that consume nearly 20 percent of US Gross Domestic
Product, are straining the ability of the government to deliver quality care.
One way to ease this strain on our national budget would be to use technology
to enable the aging population to age at home. Technology could be used to
support the independence of the elder through monitoring the activities of
daily living (ADL), tracking cognitive health, proactively managing chronic
health conditions, alerting to falls, and providing a system to promote social
engagement. This alerting, monitoring, and tracking can be done via homebased technologies that provide information to formal and informal caregivers.
Effectively, with the use of technology, the care model shifts from a large
centralized, provider-centric one to a home- and community-based model of
distributed care.
Introduction
In this article, we review a variety of tried and tested technical solutions to
address the care and needs of the elderly in the United States. Our solutions are
broadly characterized into three types: surveying, sensing, and social care.
•• The surveying solution involves periodic interactive dialogues with the
senior to assess functional, physical, and mental health while also providing
a communication platform for health education. Queries may be as
simple as a repeated list of standard questions or as complex as a system of
personalized, condition-specific questions with branching logic.
•• The sensing solution is achieved by using active or passive sensing
technology to collect information about the person’s behaviors, activities,
and functional status.
•• The social care solution involves encouraging seniors and providers to
actively participate in social communities, nurture relationships, and to
break down social isolation as individuals age-in-place alone.
We show how these three technical solutions were used by seniors and
providers to enable personal healthcare, enhance care, and improve quality of
life.
40 | Adapting Technology for Personal Healthcare
A Stressed Healthcare System
In the past, the majority of people in the United States did not live beyond 50
years of age. In 1900, for example, life expectancy was 47 years of age. In 2010,
life expectancy in the United States will exceed 80 years of age [1]. As a result,
there are now more than 39 million Americans over the age of 65. Globally, the
current population of individuals aged 65 years and older exceeds 500 million.
By 2030, it will exceed 1.5 billion. The existence of hundreds of millions of
individuals aged 65 and older is a 21st-century phenomenon [2].
“The existence of hundreds of millions
of individuals aged 65 and older is a
21st-century phenomenon.”
Historically, when the need for long-term care occurred, this need was met by
family members. It was only in the last century that long-term care emerged
as an industry. The 1940s were marked by a surge in the construction of
traditional nursing homes and the institutionalization of care. The 1960s saw
the establishment of Medicare (the government-run, healthcare system for
the elderly), Medicaid (a government-funded, healthcare system for certain
low-income individuals and families), and the establishment of the Older
Americans Act that launched a series of services designed to support aging-inplace and home-based care. Over the past twenty years, we have witnessed the
shift toward home- and community-based care, as seen in the rapid growth of
the senior housing industry and the creation of numerous, innovative models
of aging-in-place services.
Today, long-term care is prevalent and the costs are staggering:
“These factors create a tremendous
•• Over 40 percent of US households are involved in providing elder care [3].
opportunity for technology to play
•• The average out-of-pocket cost to family caregivers exceeds $5,500
annually [3].
•• The cost to employers due to lost productivity and absenteeism exceeds
$1,142 per year per employee [4].
•• The average annual cost of nursing homes exceeds $72,000 [5].
•• The average annual cost of assisted living services exceeds $30,000 [6].
a role in enabling personal care,
enhancing healthcare, improving
quality of care, and relieving some of
the stress on the healthcare system.”
As baby boomers (a term used to describe those born during the post WWII
baby boom) move into their 70s, the demand for long-term care services will
rise dramatically. If nothing is done, this additional demand could break the
long-term care system. However, these factors create a tremendous opportunity
for technology to play a role in enabling personal care, enhancing healthcare,
improving quality of care, and relieving some of the stress on the healthcare
system.
Adapting Technology for Personal Healthcare | 41
Users of a Technology Enabled Personal Care
System: Seniors, Caregivers, and Family
Independent
Living Services
Independence
Demographic
Active Boomer adults
in the workforce;
sandwich generation;
new healthcare
consumers
Average Length
of Service: 20 years
Services
• Cognitive fitness
• Informational portals
• Healthy aging and
maintaining youth
• Discounts
55+
Assisted
Living Services
Demographic
Beginning of functional
decline; living w/chronic
disease –
“uh oh moments”
Average Length
of Service: 4–6 years
Services
• Cognitive fitness
• Medication
management
• Lite IALD and
ADL support
• Chronic Disease
Management lite:
Healthy Heart
• Meals
• PERS/Safety
75+
Skilled Nursing
Services
Demographic
2+ ADL issues;
Alzheimer’s; Faller
Average Length
of Service: 2–3 years
Services
• Support of 2+ ADLs
• Cognitive Health
• Active Falls
• Wandering
• Post-acute
episode care
• Functional foods/meals
• CDM
• PERS/Safety
80+
Demographic
Seriously ill, end
of life; need for
constant supervision
Average Length
of Service:
0.5–2 years
Services
• Active medical care
• 24/7 monitoring
• Active ADL support
• Meds management
• Chronic Care
85+
Average Age
Figure 1: Transitioning through the Aging Services Continuum
“The senior, caregivers, and family
form a triad to address emerging and
evolving needs.”
As individuals transition though the second half of life, they traditionally
proceed through stages of increasing functional, physical, and cognitive decline
over time, as shown in Figure 1. For some individuals, this is a slow, gradual
process. Other individuals maintain healthy and active lifestyles until the very
end of life. In either case, throughout this process, the senior, caregivers, and
family form a triad to address emerging and evolving needs.
At-home technology can complement the work of caregivers such as physicians,
nurses, wellness coaches, care coordinators, family members, neighbors, and
friends. Technology provides new and innovative ways to monitor the wellbeing
of older people, increase the levels of communication between all concerned,
and enable response to rapidly changing conditions. The new awareness that
long-term care includes clinical and non-clinical caregivers as well as local and
distant family and friends is playing a large role in transforming long-term care
services.
“For caregivers, home-care systems
mean more efficient and effective
healthcare, driven by seniors who take
greater responsibility for their own
health.”
Home-care systems allow people to monitor themselves with devices that
give proactive warnings of illness, thereby enabling patients to turn to their
caregivers earlier, when intervention can be the most effective. For caregivers,
home-care systems mean more efficient and effective healthcare, driven
by seniors who take greater responsibility for their own health. William
Herman, director of the Division of Physical Sciences in the Food and Drug
Administration’s Center for Devices and Radiological Health (CDRH), calls
home-care systems “the fastest growing segment of the medical device
industry” [7].
The Home Environment
In developing technologies to support aging-in-place and to enhance long-term
care, the following key principles should be kept in mind:
•• The focus is healthcare; often a new technology is not what is needed;
instead, the application of an existing technology might be appropriate.
“Two of the biggest challenges to the
•• At the center of this healthcare issue are the senior and the caregiver, not
the technology. Without cooperation from the users of the system, the
system may never be useful.
usability and installation.”
utilization of technology in a home are
•• There is often more than one way to achieve a clinical or care objective: the
first technology solution that appears may not be the best.
•• The simpler the technology, the better.
•• Technology solutions for healthcare are mission-critical; reliability is of
paramount importance.
•• The technology has to work in the home, not just in the lab.
•• Usability by the senior and the caregiver is paramount.
Two of the biggest challenges to the utilization of technology in a home are
usability and installation. The usability issue is critically important in that
compliance often hinges on usability. For what we call our survey and social
care solutions to work, issues regarding user interfaces, choice of display colors
and font sizes, method of interaction, device type, device size, and portability
have a significant impact. For a solution to reside in an individual’s home, we
must understand where a system will be used and the available space in the
home for that system.
The installation issue is particularly challenging. Often a new technology
requires multiple devices, batteries, cables, cable management, and wireless
data connections. Integrating all of these components and installing them is
often more challenging than anticipated.
Moreover, variability in home construction material, room size, room layout,
and environmental factors (lightning and air flow) can impact the technology
deployed and the reliability of the results. For our sensor solutions, ongoing
maintenance requirements, such as changing batteries, repositioning sensors, or
updating the type of sensor, may also create obstacles to adoption.
Ironically, while technology may feel threatening to those in the home, the
home environment is actually a fairly inhospitable place for technology.
Drops, strikes, water damage, and tampering, among other things, are very
likely to occur in a home and must be anticipated when technology is being
designed. Children, in many cases more technology savvy than their parents or
grandparents, are an active threat and may drive new security requirements that
require biometric authentication and tamper-detection technologies.
“Drops, strikes, water damage, and
tampering, among other things, are
very likely to occur in a home and
must be anticipated when technology
is being designed.”
“A technology will benefit from a
design that enables the parts of the
technology to function, potentially all
over a home, but not draw unwanted
attention to the resident’s health.”
Finally, another goal of in-home monitoring technology should be that it
be hidden in plain sight. Being readily available and convenient are critical
elements for fostering regular use, but many people with chronic disease have
no desire to share that part of their life with others. Therefore, a technology
will benefit from a design that enables the parts of the technology to function,
potentially all over a home, but not draw unwanted attention to the resident’s
health. The use of Personal Emergency Response System (PERS) devices is a
classic example of a market reaching a premature plateau because of the stigma
attached to wearing a PERS pendant. PERS market penetration has flattened to
a 16 percent adoption rate due to this usage issue and 40 percent of PERS users
do not wear their pendants.
We now explore in more detail the three technology solutions that we evaluated
and tested: surveying, sensing, and social care.
Surveying
“Wellness surveys are one way to
approach behavior assessment,
encourage change, and achieve better
outcomes.”
It is now known and accepted that proactively managing health can lead
to healthier choices, improved accountability, increased quality of life, and
enhanced health. In an era where chronic disease is the leading cause of
hospitalization and the major driver of healthcare expenditures, engaging
individuals to modify behavior and make better lifestyle choices can have a
profound impact on health, wellness, utilization of services, and system costs.
Wellness surveys are one way to approach behavior assessment, encourage
change, and achieve better outcomes.
Wellness Coach and Surveying
The increased awareness of the importance of proactively engaging individuals
in managing their own health has led to a proliferation of health coaching
services. From the Mayo Clinic Embodied Health Services to numerous mobile
health applications, these services run the gamut from clinical to consumerfocused programs.
“Our surveying research involved
periodic interactive testing or queries
of the elder in their homes to estimate
physical, functional, and mental
health.”
Through the efforts in the Product Research and Incubation Group, we have
conducted numerous research initiatives around the concepts of wellness
coaching and surveying. We also employed non-clinical wellness coaches to
use technology to improve the cognitive and social health of seniors, as well
as to use surveys to explore how seniors could stay at home and age with as
much dignity, independence and functional, cognitive, and physical health as
possible.
Our surveying research involved periodic interactive testing or queries of
the elder in their homes to estimate physical, functional, and mental health.
This interactive testing involved using either dedicated testing hardware or
measurable extensions of existing household items or activities.
Our surveying methodology varied. In some cases, we used queries ranging
from as simple as a repeated list of questions. In other tests, we used queries
as complex as a system of branching logic. The ability to have flexibility in
the surveying methodology allows for the healthcare or eldercare provider
who monitors survey answers to customize future queries or test sequences to
specific patient situations.
“Sensors strategically placed on the
human body create a wireless body
area network (BAN).”
Sensing
Any at-home healthcare solution must detect and respond to the activities
and characteristics of the older person. A network of sensors (either worn,
carried, or environmental) is a good platform for detecting and responding to
health-relevant parameters, such as movement, breathing, pulse, heart rate, or
social activity. Sensors strategically placed on the human body create a wireless
body area network (BAN) that can monitor various vital signs while providing
real-time feedback to the user and medical personnel. Further, wireless sensors
can be deployed in a patient’s home environment to provide real-time and
extended monitoring of activity and wellbeing.
When coupled with communications technologies, such as mobile phones and
the Internet, the wireless sensor network (WSN) can keep family, caregivers,
and doctors informed, while also establishing trends and detecting variations
in health. Appropriate technology design can minimize intrusion and protect
privacy, maximize user friendliness, and encourage long-term adherence to
medical regimens.
“For example, changes in gait might
indicate the onset of Parkinson’s disease
in advance of visible symptoms.”
In some cases the wireless sensor network requires no direct patient interaction
(this is ideal where the patient may be suffering from some level of cognitive
decline). Because WSNs are deployed where the patient spends most time, they
can deliver long-term data sets to assist in diagnostics and patient response to
interventions. The data collected by a WSN can be stored and integrated into
a comprehensive health record of each patient that may allow identification of
subtle changes in a person’s health. For example, changes in gait might indicate
the onset of Parkinson’s disease in advance of visible symptoms [8]. Other
example applications include medicine reminders, social connectivity, and
emergency communications.
BANs can detect small changes in vital signals — such as heart rate and bloodoxygen levels — that are not obvious in a one-off visit to a doctor. Further,
BANs address the issues associated with so-called “white coat syndrome,”
skewed physiological and cognitive test results that are related to the stress
and anxiety associated with a clinical visit. Measurements can be made
unobtrusively over an extended period in a supportive home environment that
more accurately reflects the true values for a given parameter.
“Measurements can be made
unobtrusively over an extended period
in a supportive home environment
that more accurately reflects the true
values for a given parameter.”
“WSNs can provide notice of
significant shifts in key physiological
parameters and may save lives, or
initiate preventative care in order to
forestall a health crisis.”
As well as offering excellent long-term care benefits, the always-on nature of
WSNs means that they can be used to detect and respond to health crises in a
timely manner. In particular, WSNs can provide notice of significant shifts in
key physiological parameters and may save lives, or initiate preventative care in
order to forestall a health crisis.
The potential value of WSNs for healthcare has not yet been fully explored. A
significant research effort will be required to mine the vast data sets collected by
WSNs and to find patterns that reveal information of interest to the healthcare
professional. Breakthroughs in this area may support semi-automated analysis,
diagnosis, and treatment processes in the future. Doctors will be assisted
by an electronic counterpart, and patients’ health may benefit as a result of
faster diagnosis and treatment of diseases. Other quality-of-life issues, such as
privacy, dignity, and convenience, are supported and enhanced by the ability to
unobtrusively provide services in the patient’s own home [9].
Overview of our Methodology
In this section we present an overview of our general methodology for a WSN
solution. Specifically, here are criteria for developing and deploying a WSN in
healthcare [10].
•• Understand the problem. A clinician may already have analyzed the problem,
and have come up with a technology outline for the engineer to develop.
However, further analysis may pay dividends. At-home healthcare means
that the appropriate environment to formulate any technology solution is
not the clinic or the laboratory, but the home. Ethnographic observation
of user behavior, where an understanding of how people live and why they
live as they do, their constraints and their priorities day to day, can be very
beneficial and has informed many of the solutions in which we are involved.
•• Understand the end user. Who will use the solution in the longer term?
What are their constraints or priorities? How do they feel about the type
of solution envisaged? Usage modeling, where multi-disciplinary teams use
personas to explore the user experience from several perspectives, can be
useful here.
“Breakthroughs in this area may
support semi-automated analysis,
diagnosis, and treatment processes in
the future.”
•• Understand what data must be collected. In order to test a clinical hypothesis
or to achieve a care objective, some information about the activity or
health state of the patient must be collected. It is important that a clear
understanding of what data will be collected by the sensor network is
shared by the clinician and the engineer, from the start. The information
that the clinician needs is important, not the data that the sensor has the
technological capability to collect. Focus on what is needed, rather than on
what the technology allows.
•• Understand the environment. Many WSN deployments do not achieve their
objectives because they fail to take into account the differences between the
laboratory and clinical environment, and the home environment. Building
methods and materials vary from location to location; these may impact
the technology. Other equipment in the home may also interfere with the
sensor technology.
•• Consider sensor location. Are sensors to be worn, to be held, to be embedded
in walls, floors, beds, or furniture? Keep in mind that the sensor network
must be as unobtrusive as possible — solutions that require the patient to
change his or her day-to-day behavior or which affect the comfort, privacy,
or dignity of the elder person are unlikely to be successful on a long-term
basis. Almost all at-home solutions aim to be long-term.
•• Select sensors and actuators. Take into account the data, the environment,
and the placement. What impacts do these have on power consumption,
size and weight, form factor, radio communications, antenna type
and computational capability? Where at all possible, use off-the shelf
components, and avoid experimental or prototype technology. Remember
this is a healthcare problem, not a technology research project. Aim for a
low-cost, light-touch solution.
•• Specify and build the aggregator. The aggregator receives data from all the
sensors in the network, and may transmit them to an analysis engine or
data visualization system. Alternatively, the aggregator may itself process
the data and trigger responses by actuators or by communications with
caregivers or doctors. In general, actuators take the form of local PCs
or mobile devices, such as PDAs and smart phones. We do not cover
aggregator design in any detail in this article, because one typically uses
mass-market devices such as phones and PCs.
•• Identify and deploy analysis and visualization capability. Ensure that the
technology is in place to convert the data from the WSN to clinical
information, and to allow the clinician to access this information in an
appropriate manner. This may be out of the scope of a purely sensornetwork project, but it is important that in such a case the precise nature
of the interface between the network and the back-end data analysis and
clinician system is clearly defined. The technology used for visualization
is not explored in this article; analysis and visualization techniques and
technologies are quite standard across many application domains.
•• Build the solution in the laboratory and verify that all elements work as
planned. Discuss the solution with clinicians and end users.
•• Prototype and pilot test the solution in a controlled, friendly environment.
The solution should be used in the home of a study participant who has
agreed to act as a tester. In these friendly trials, the importance of proper
safety testing and precautions cannot be understated. Before deployment
to the home even for prototyping purposes, any Federal Communication
Commission licenses or local radio licenses, UL or CE requirements,
human subjects approvals, Institutional Review Boards (IRBs, signed
agreements, etc.) must be obtained.
•• Deploy the solution in the real world. Continue to engage with end-users to
detect and correct any issues that may lead to failure to use the solution as
planned.
“Medication compliance is a vexing
issue at the core of many challenges in
healthcare.”
Overall, we have learned that deploying an effective sensor solution is
a complex endeavor. As such, proactive planning, clear objectives, and
forethought of the end-stage solution are critical to a successful design and
deployment of a WSN solution.
Context Aware Medication Compliance (CAMP) Trial
Medication compliance is a vexing issue at the core of many challenges in
healthcare. In a recent report in the New England Journal of Medicine, Osterber
and Blaschke [11] report that typical adherence to a medication regime ranged
from 43 percent to 78 percent, depending on the age of the population
researched and the type of medication taken. In other words, 50 percent of
patients are typically failing to comply with their medication regimen.
Our team engaged in a context aware medication compliance (CAMP) trial
to develop a sensor network system that is contextually aware. We wanted to
test adherence to a medication regime over several months, in the hopes of
improving the rate of adherence over time.
“Our system was designed to track
the location of users, monitor the
sleep activity of users, monitor the
adherence to medication regimens,
and drive prompts to various devices
throughout the home.”
Typical products on the market for medication adherence fall into two
categories. The first is the product that acts like a timer or alarm clock. These
devices issue alarms when the time set for people to be reminded to take
their medication is reached. Although these devices are highly accurate in
measuring time and delivering an alarm, they often were not co-located with
the medication at the time of alarm. Moreover, these alarms prompted so often
that they became a nuisance and were often overlooked. Other devices are store
and dispense medications. These are common in many households and take
the form of a system with cells in multiples of seven for the days of the week.
Medication is stored in these devices, and the device is often located near the
activity center associated with the time of day the medication should be taken.
These systems fail when the user’s routine is disturbed.
Our system was designed to track the location of users, monitor the sleep
activity of users, monitor the adherence to medication regimens, and drive
prompts to various devices throughout the home, based on the appropriate
time, location, and activity that would ensure the best adherence.
Planning Sensor Deployment
A key issue for planning is the layout of the deployment environment (the
subject’s home) and the identification of ideal sensor locations. Ideal locations
reflect the range of the radios being used (Zigbee*, Bluetooth*), the size of the
rooms, and the sensitivity of motion sensors. Figure 2 shows an example floor
plan with sensor locations. The sensor locations must be verified and validated
after the installation, to ensure that data are being captured and communicated
as planned.
Base station
Livingroom
Bed sensor
Imed
Pillbox
Bedroom
Closet
Watch charger
Kitchen
DSFridge
Bathroom
Closet
Door sensor
Activity beacon
Motion sensor
Phonejack
Ceiling motion sensor
Cable connection
Figure 2: Floor Plan and Sensors Placement
The choice of radio technologies can have a profound impact on the success of
communications within a project. Similar devices from different suppliers may
perform in dramatically different ways.
Moreover, we learned through deployed trials in US homes throughout the
Southwestern United States and the Pacific Northwest that construction
methods and materials profoundly affect wireless technology. Homes with
significant wood and lumber construction create a very different environment
than do homes constructed of stucco, steel frames, and other materials.
“The choice of radio technologies can
have a profound impact on the success
of communications within a project.”
Surprising at the time, although obvious now, we learned that variation in
the materials and methods of home construction had a significant impact
on sensor performance. As such, understanding the materials used in home
construction has a direct impact on both the type of sensors selected and the
manner in which a WSN will be designed and deployed.
Participant Tests
In the course of the CAMP project, we deployed a pillbox with sensorequipped doors. Each time a door in the pillbox was opened, a signal was sent
to the aggregator, indicating that a pill had been taken. However, one subject
left the door open, as a reminder to himself to take the second pill; this was not
as envisaged by the team, and it led to unexpected inferences by the system.
“Each time a door in the pillbox
was opened, a signal was sent to the
aggregator, indicating that a pill had
been taken.”
“Frequent at-home monitoring of
disease state tends to be far superior
to infrequent but highly detailed inclinic assessments.”
Fluorescent Lamps and Infrared Signals
Common fluorescent lighting fixtures driven by electronic ballasts emit
low-frequency infrared signals modulated in the kilohertz range. This signal
interferes to a very significant degree with infrared communications between
devices and aggregators, or among devices. Interference from fluorescent
lighting needs to be taken into account when choosing the technologies to
deploy, and also when positioning devices in the home. It should be borne in
mind that some applications of fluorescent lights mean that they are used only
occasionally, such as for lighting on kitchen counters.
Parkinson’s Disease At Home Test
One option where technology in the home may improve upon the modern
hospital and clinic framework is in the area of interactive monitoring of chronic
or degenerative diseases. An ecosystem of technologies has grown around a
few individual diseases, such as diabetes, and frequent at-home monitoring of
disease state tends to be far superior to infrequent but highly detailed in-clinic
assessments.
“Designers and engineers at Intel
created an At Home Test (AHT) for
Parkinson’s disease.”
In 2004, we were approached by a not-for-profit Parkinson’s Disease research
support foundation interested in technologies to better monitor the symptoms
of Parkinson’s disease. This interest was fostered by a series of meetings between
the foundation and prominent neurologists from seven different institutions.
Each of the neurologists present had recent experiences with various techniques
to quantitatively measure the symptoms of Parkinson’s disease. Together, the
neurologists expressed interest in a single apparatus, designed around multiple
measurement techniques, and capable of daily or weekly evaluations of the
symptoms of Parkinson’s disease outside of a clinic or lab [12].
Historically, Parkinson’s disease testing has consisted of twice or three times
yearly visits to a neurologist, where somewhat subjective estimates were made
of the patient’s condition by using the Unified Parkinson’s Disease Rating Scale
(UPDRS). While the UPDRS has been a gold standard for years, the neurology
team and the foundation felt its typical application lacked frequency and did
not produce truly quantitative measurements.
Intel, the Parkinson’s Disease foundation, and the team of neurologists formed
a set of requirements and a study protocol to (1) establish evidence that
in-home interactive sensing of Parkinson’s disease is viable and would be used
by patients on a regular basis, (2) assess the effectiveness of the various
quantitative measurement techniques brought forward by the team of
neurologists, and (3) establish if those measurement techniques could show
variation in measured symptoms from week to week. Based on this set of
requirements and the new protocol, designers and engineers at Intel created an
At Home Test (AHT) for Parkinson’s disease.
Figure 3: The Parkinson’s Disease At Home Test
Apparatus
The AHT was designed to measure the following:
“The study consisted of 52 subjects,
•• Large limb motion
all in the early stages of Parkinson’s
•• Fine motor skills
disease, who each took an AHT
•• Fatigue
•• Ability to maintain rhythm
•• Tremor frequency and duration
apparatus home for six months of
once-weekly testing.”
•• Reaction time
•• Free speech (voice inflection)
•• Continuous vocal tone
Metrics designed around gait measurement or other ambulatory situations were
rejected from final design, due to the potential for possible subject injury when
subjects were in an unsupervised environment.
The study consisted of 52 subjects, all in the early stages of Parkinson’s disease,
who each took an AHT apparatus home for six months of once-weekly testing.
Prior to the six months of weekly tests, the subjects each took a test once every
day for a week to ensure they were well practiced with the movements and
to ensure that future study results would not reflect a learning curve. After
the practice sessions, the subjects were evaluated by their clinician to see if
they could actually follow the study directions. All but one subject was fully
enrolled after practice, with the one missing subject disqualified due to other
health reasons. In general, subjects proved capable of using the AHT apparatus.
Due to the relatively late onset of Parkinson’s disease symptoms (average age at
diagnosis is 59) for most subjects, certain design considerations were taken into
account:
•• Failing eyesight.
•• Reduced range of hearing.
•• Discomfort with complex technology.
•• Presence of grandchildren who might tamper with or damage the
equipment.
Furthermore, because a movement disorder was known to afflict the study
subjects, we employed large buttons in a widely spaced configuration for all
navigation and selection tasks. We did not use any mouse or other pointing
device. Instead, subjects used just up, down, and select interaction buttons.
The likelihood of participants having failing eyesight was mitigated by
integrating a super bright and relatively large liquid crystal display (LCD) into
the Parkinson’s disease AHT apparatus. The LCD had large fonts and provided
a lot of empty space within screens. Furthermore, we provided all instructions
and cues in both text and through a voice reading of the text. Reduced hearing
ability was accommodated by using a large speaker and selecting an instruction
narrator with a lower-toned voice.
“We employed large buttons in a
widely spaced configuration for all
navigation and selection tasks.”
“We developed significant data
security to ensure the authenticity of
the information could be established
and that the health information
within the test data could be protected
from unauthorized viewing.”
At-Home Testing Program
3:49 PM
Take Tests
Friday, May 30
• Instructions
Move Up
Next test session
Select
Saturday 5/31
Move Down
4:00pm – 8:00pm
Reaction Test
“BEEP”
Finally, we made the design decision not to use a standard computer, where
booting and peripheral connection could interfere with regular use of the
AHT apparatus. Instead, we prototyped a series of small netbook-like devices
with integrated tests. The form-factor we selected in the end was rugged, small
enough for regular use on a counter or kitchen table, easily transported, and
nondescript so as to encourage subjects to leave it out and plugged in.
The initial intent was to have the Parkinson’s disease AHT apparatus connect to
a home network. After extensive review of the availability of high-speed
Internet, however, together with concerns about integrating the AHT apparatus
with existing home networks, we made the design decision to simply store test
data for later delivery to a central storage facility either physically or through a
computer Internet connection. We later decided to include a very basic and
inexpensive laptop computer equipped with a mobile broadband card to
facilitate more regular uploads of study data.
We anticipated that the AHT apparatus might incur system failures in the
field, so we also made the design decision to store all application software and
study data on an external storage device. This decision allowed us to replace a
defective system in the field without having to modify it for use by a specific
study participant or extract test data from a damaged unit. New systems
could simply be sent to replace defective or damaged ones, while the damaged
systems could simply be discarded. We decided on a USB storage device as the
medium and we developed significant data security to ensure the authenticity
of the information could be established and that the health information within
the test data could be protected from unauthorized viewing.
Because the systems were going to be deployed over much of the United States,
we designed the software system to be easily upgraded. Upgrades were provided
either through issuing new USB storage devices or by updating the software on
the storage devices during the data upload process. We also designed packaging
to protect the apparatus during air or ground freight.
The final AHT apparatus design was very well received [12] and even won a
major design award in 2006. All but one study participant found the device to
be easy to work with.
Although careful consideration and a great deal of organizational effort went
into building the AHT apparatus, we learned many lessons the hard way. As an
initial foray into the healthcare field, these lessons were as valuable, if not more
so, than anything the actual study might tell us.
First and foremost, we learned the value of very careful industrial design and its
impact on end-user acceptance. The system was beautiful and people wanted to
use it. Something less refined would have begged to be put in a drawer.
Figure 4: Parkinson’s Disease At Home Test
Screen Shot
On the study side of things, we found that training was critical, especially for
the clinicians who would oversee the study subjects. They were the first line of
support for subjects and, in many cases, solved problems without our input
(until the end of the study). What seemed excessive at the time, flying all of the
clinicians to our offices at Intel for a day of intense training, turned out to be
money and time very well spent.
Finally, we found that the sheer volume of data collected by the AHT
apparatus to be intimidating, even to seasoned statisticians. There were so
many dimensions for analysis that forming a coherent plan to correlate
measurements with UPDRS scores was difficult.
“What seemed excessive at the time,
flying all of the clinicians to our offices
at Intel for a day of intense training,
turned out to be money and time very
well spent.”
In the end, we found that individuals with Parkinson’s disease would likely use
this type of interactive technology on a regular basis in their homes if it was
widely available. We also found that some quantitative measures showed a lot
of promise in predicting disease state [12], but the initial study was not sized
to prove any such assertion. The data, arguably one of the largest collections
of Parkinson’s disease measurements, have proven useful for additional
investigations into the progression of this disease.
We now move on to a discussion of the third aspect of our technology
healthcare solutions, what we call social care.
Social Care
Studies have shown that social isolation can lead to depression and loneliness
and can accelerate the onset and manifestation of illnesses of aging. In May
2009, the New York Times ran a front-page story on the increased use of social
media by senior citizens — and the direct and indirect health benefits of such
social engagement. There have been many other articles and reports discussing
the link between an individual’s health and the size and activity of their social
network [13].
“There have been many other articles
and reports discussing the link between
an individual’s health and the size
and activity of their social network.”
In April 2009, The California Healthcare foundation released a report titled:
The Wisdom of Patients: Health Care Meets Online Social Networking [14].
This report illustrated the strong growth of web 2.0 offerings focused on
providing information and community to seniors and aging baby boomers.
The report indicated that the active participation in social networks would
be the hallmarks of a consumer-centric approach to healthcare. The access
to health information, quality data, and provider rankings, coupled with
the establishment of forums, sites, and support groups to rapidly exchange
information, are fundamental shifts in how healthcare is provided.
Social Health Trials
“We hypothesized that we could
detect and track the social activity of
a patient with Alzheimer’s disease,
while also providing feedback on that
activity to the patient and a family
caregiver.”
One of Intel’s earliest research projects focused on examining social networks
and social health. We hypothesized that we could detect and track the social
activity of a patient with Alzheimer’s disease, while also providing feedback
on that activity to the patient and a family caregiver. The desired result was
to keep the patient as socially engaged as possible. To that end, we queried
each participant to define a social network of approximately ten friends and
family that were to be tracked. We built a sensor network in the home of each
participant that was designed to detect and track physical visits and phone calls
by anyone in the predefined social network.
We also built two interfaces that the patient and family caregiver could interact
with: one was a caller ID application that rendered a picture and provided
contextual notes regarding the last conversation between the patient and friend
or family member, as well as a social networking galaxy model. The galaxy
model provided a picture of the patient in the center of the graphical universe
with pictures of the social network participants orbiting around the patient.
As more or less social activity was detected by the sensor network, the orbit of
each participant changed and became closer or further away from the patient,
respectively [15]. This provided a simple model for the patient to use to reflect
on their level of social activity with any given participant in their network. For
example, if a patient’s daughter hadn’t called in a few weeks, the patient could
see in the galaxy the orbit becoming more distant. Conversely, the orbits of
those with whom the patient had more frequent contact would become closer.
“For example, if a patient’s daughter
hadn’t called in a few weeks, the
patient could see in the galaxy the
orbit becoming more distant.”
Participants found the interfaces compelling, keeping them more mindful
of changes in their social activity than they otherwise would have been [15].
New models of interaction, particularly those focused on what one might call
interactive journaling of patterns and daily activities are promising solutions for
keeping home-bound seniors and patients engaged and connected in their daily
lives.
Conclusions
In this article, we examine the impact of the transformation occurring across
many parts of the world with regard to healthcare. Increased longevity and
the aging of the baby boomer population are creating a sea change in the
demographic composition of populations across the globe. Correspondingly,
societies are shifting from youth-orientated cultures to age-aware cultures.
Healthcare systems are shifting from treating the acute illnesses of youth to
managing the chronic illnesses of aging.
All of this is occurring at a time when healthcare is consuming more than 17
percent of the United States’ GDP, the quality of care is deteriorating, and the
healthcare delivery system is more challenged than ever. Meanwhile, more than
40 million people in the United States lack healthcare insurance. Millions of
others lack access — or cannot afford access due to the cost of care.
One solution to ease some of these strains on the healthcare system may be
to use technology to enable the aging population to age at home. Technology
can support independence of the elderly through monitoring activities of
daily living (ADL), tracking cognitive health, proactively managing chronic
health conditions, and providing a system to promote social engagement. All
of these services can be provided at home with the help of informal caregivers.
Moreover, informal home caregivers help to alleviate the shortage of skilled
nurses in the workforce today. Effectively, this technology shifts the care
model from a large, centralized, provider-centric care model to a home- and
community-based model of distributed care.
“Increased longevity and the aging
of the baby boomer population
are creating a sea change in the
demographic composition of
populations across the globe.”
We have shown how three technical solutions were used in trials, by adapting
technology to enhance the quality of life for patients, while at the same time,
providing a platform for proactive health and wellness management for
providers. The adoption of these solutions can play a major role in changing
the playing field, improving quality of care, and improving health outcomes.
“The adoption of these solutions can
play a major role in changing the
playing field, improving quality of
care, and improving health outcomes.”
References
[1]
J.E. Cohen. “Human Population: The Next Half Century.” Science, 14
Nov. 2003, pp. 1172-1175.
[2]
J.E. Cohen. “Human Population: The Next Half Century.” Science, 14
Nov. 2003, pp. 1172-1175.
[3]
“Family Caregivers — What They Spend, What They Sacrifice. The
Personal Financial Toll of Caring for a Loved One.” Evercare and the
National Alliance for Caregiving, November 2007, page 9.
[4]
“The MetLife Caregiving Cost Study: Productivity Losses to U.S.
Business.” MetLife Mature Market Institute and National Alliance for
Caregiving, July 2006.
[5]
“Genworth 2009 Cost of Care Survey: Home Care Providers, Adult Day
Health Care Facilities, Assisted Living Facilities and Nursing Homes.”
April 2009. Genworth Financial, page 8.
[6]
“Genworth 2009 Cost of Care Survey: Home Care Providers, Adult Day
Health Care Facilities, Assisted Living Facilities and Nursing Homes.”
April 2009. Genworth Financial, Page 18.
[7]
C. Lewis, “Emerging Trends in Medical Device Technology: Home Is
Where the Heart Monitor Is.” http://www.fda.gov/
[8]
B. Schlender. “Intel’s Andy Grove: The Next Battles in Tech.” Fortune,
12 May 2003, pp. 80-81.
[9]
J. Takamura and B. Williams. “Informal Caregiving: Compassion in
Action.” An informal report, US Department of Health and Human
Services, 1997.
[10] Dishongh, T. and McGrath, M. Wireless Sensor Networks for Health Care
Application. Artech Publishing, New Jersey, 2009.
[11] Osterberg, Lars, and Blaschke, Terrence. “Adherence to Medication.”
New England Journal of Medicine, Volume 353:487-497, August 4,
2005.
[12] Deleeuw, Bill. “Testing objective measures of motor impairment in
early Parkinson’s disease: Feasibility study of an at-home testing device.”
Movement Disorders, Volume 24(4): 551-6, March 15, 2009.
[13] “A Reason to Keep On Going.” New York Times, June 12 2009, Health
Section, page D5. By Stephanie Clifford, Reporter.
[14] “The Wisdom of Patients: Health Care Meets Online Social Media.”
April 2008. The California Healthcare Foundation. Health Report, by
Jane Sarasohn-Kahn, THINK-Health.
[15] Morris, M. “Social Networks as Health Feedback Displays.” IEEE
Internet Computing, vol. 9, no. 5, pp. 29-37, Sept./Oct. 2005.
Acknowledgements
We acknowledge with thanks the hard work of our co-workers: Kevin Rhodes,
Brad Needham, Margie Morris, Jay Lundell, Eric Dishman, Tim Plowman,
Steve Agritelley, and Adam Jordan.
Author Biographies
Terrance (Terry) J. Dishongh, Ph.D., is currently a Senior Principal Engineer
in the Intel Digital Health Group. In his twelve years at Intel he has been
awarded 48 patents with an additional 44 pending and has published books
on wireless sensors and electronic packaging. Dr. Dishongh has held faculty
positions at the University of Maryland, College Park and the State University
of New York at Buffalo. His e-mail is terry.dishongh at intel.com.
William (Bill) DeLeeuw is an 18-year veteran of Intel and currently is an
“Innovation Architect” in the Intel Digital Health Group. He is responsible
for creating new health concepts consistent with Intel’s digital health strategy,
prototyping those concepts, and working with study coordinators to establish
feasibility. Bill has worked on PC FAX systems, applications sharing software,
consumer video conferencing, distance learning, consumer electronics,
experimental wireless systems, and user-centered design concepts. He received
a Bachelors of Science degree in Electrical Engineering from the University of
Texas in 1991. His e-mail is bill.deleeuw at intel.com.
Mark Francis, M.P.P., is a Product Marketing Manager in the Intel Digital
Health Group. Prior to joining Intel, Mr. Francis held senior management
or Board positions with Harrison Clinical Research, Health Hero Network,
Age Wave, and the City of Boston. Mark conducted his academic work at
the Harvard Business School, Harvard Kennedy School and the University of
Pittsburgh. His e-mail is mark.r.francis at intel.com.
Copyright
countries.
Healthcare IT Standards and the Standards Development
Process: Lessons Learned from Health Level 7
Contributors
Charles Jaffe
Health Level 7
W. Edward Hammond
Duke University
John Quinn
Accenture
Robert H. Dolin
Health Level 7
Abstract
Standardization of information in healthcare is critical to the ability of a diverse
community of caregivers to reliably exchange complex data without ambiguity.
Perhaps more importantly, every member of the healthcare team must be able
to re-use the data within increasingly diverse applications and environments.
In order to improve quality and to constrain the escalating costs of delivering
care and preventative medicine, the strategies for developing these standards
have attempted to keep pace with the developments in information technology,
human biology, healthcare policy, social science, and economics. For more than
two decades, Health Level 7 has been at the forefront of those processes for an
international community. New technologies, and new applications of existing
ones, foster standards development against a complex backdrop of social and
political demands.
Healthcare IT Standards: An International Perspective
Index Words
Healthcare Information Standards
Health Level 7
“Health Level Seven (HL7) was
organized in 1987 to create standards
The history of standards has made the creation of standards difficult. The
global community of today did not exist when the healthcare IT community
recognized the necessity for health data standards to reduce the costs of
interfacing systems and to permit the exchange of data. The health-related
community began to be interested in standards during the early 1980s, and
several organizations were created during the late 1980s and early 1990s.
For clinical systems, the needs were primarily within a hospital and included
the domains of patient admission, transfer and discharge; lab test ordering
and result reporting; prescriptions and dispensing; materials management;
images; reimbursement; and other similar domains. New standards-developing
organizations were created, mainly focusing on only one component of the
many recognized needs.
Standards developing organizations (SDOs) that were creating standards in
communications, banking, manufacturing, and other non-health areas were
quite mature by this time. In the United States, ASTM American Society for
Testing and Materials created E31 for health data standards, focused initially
on standards for the reporting of laboratory test data. Health Level Seven
(HL7) was organized in 1987 to create standards to support the development
of best-of-breed hospital information systems.
to support the development of best-ofbreed hospital information systems.”
58 | Healthcare IT Standards and the Standards Development Process: Lessons Learned from Health Level 7
In Europe, the Comité Européen de Normalisation (CEN) formed Technical
Committee 251 in the early 1990s to create health data standards. There
was little competition between CEN and HL7, simply because there was no
apparent common market. In fact, the methodology that was used to create
later HL7 standards was influenced by CEN. In 1995, Germany became
the first international affiliate of HL7, followed shortly thereafter by the
Netherlands. From then on, the competition between HL7 and CEN began.
The relationship between members of both organizations was cordial, but both
HL7 and CEN were vying to have their standards used in Europe.
“The International Standards
All countries have a national standards body: the American National Standards
Institute (ANSI) in the United States; the British Standards Institution (BSI)
in the United Kingdom, the German Institute for Standardization (DIN),
the French national organization for standardization, known as Association
Française de Normalisation (AFNOR), and so on. The International Standards
Organization (ISO) was founded just after the end of World War II in 1947
and is an international, standard-setting body composed of representatives
from these various national standards’ organizations. ISO Technical Committee
215 was formed in 1998 through efforts of the U.S. and the U.K. to create
standards in Health Informatics. Since most countries, by law, require the use
of an ISO standard if one exists, ISO became a key player in international
standards. In 1991, recognizing that there were not sufficient expert resources
available for ISO and CEN to conduct their standardization activities
independently, ISO and CEN signed the Vienna Agreement to work together
to produce standards. The impact of this agreement, including the joint
development of standards and the sharing of standards, was felt independently
within each organization.
national standards’ organizations.”
Organization (ISO) was founded
just after the end of World War II
in 1947 and is an international,
standard-setting body composed of
representatives from these various
“After over five years of work, a single
standard had still not been defined.”
In 2002, HL7, following the lead of IEEE, signed an agreement with ISO,
through ANSI, that permitted HL7’s work and standards to be brought into
ISO upon approval of ISO TC 215. Although both of these agreements
resulted in a move toward the consolidation of work, standards continued to
be duplicated. In the spirit of harmonization, efforts were put into mapping
one similar standard to another across organizations where multiple standards
exist. An example of one such activity was the effort to create a single standard
for defining data types, by combining similar work from ISO, CEN, and
HL7. After over five years of work, a single standard had still not been defined.
Similarly, approaches to define a single global Reference Information Model
(RIM) failed, because of differences between the CEN standard EN 13606
and the HL7 RIM. This latter issue was further compounded when the HL7
RIM was approved as ISO/HL7 21731:2006-Health Informatics-HL7 version
3-Reference Information Model.
Healthcare IT Standards and the Standards Development Process: Lessons Learned from Health Level 7 | 59
“Over the next few years, HL7
submitted several HL7 standards to
the ISO to become joint HL7/ISO
standards.”
Over the next few years, HL7 submitted several HL7 standards to the ISO
to become joint HL7/ISO standards. These included HL7 version 2.5
Messaging Standards; HL7 version 3.0 Clinical Document Architecture, R2;
Common Terminology Server, R1; HL7 EHR–Functional Model; and Clinical
Genomics-Pedigree. In late 2005, HL7 submitted four regulatory standards to
ISO: Structured Product Labeling, Release 1; Individual Case Safety Report;
Stability Study; and Annotated Electrocardiogram.
None of these standards were accepted by TC 215 (most nations abstained).
In addition, the International Committee on Harmonization (ICH) was very
concerned, because they themselves had standards in some of these areas.
In 2006, at the International Conference on Harmonization of Technical
Requirements for Registration of Pharmaceuticals for Human Use ICH
meeting in Yokohama, leaders from ISO TC 215, CEN TC 251, and HL7
made presentations to the group about their respective organizations. As a
result, ICH became Class D Liaison with ISO and developed relationships with
both CEN and HL7.
“There was a real interest among the
leaders of ISO, CEN, and HL7 to
work together.”
There was a real interest among the leaders of ISO, CEN, and HL7 to work
together, largely driven by the limited resources available to produce standards,
as well as by the confusion in the marketplace because of multiple standards.
At the Global Health Information Technology Standards Summit in Geneva in
2006, presentations by Dr. Yun Sik Kwak, Chair, ISO/TC 215; Kees Molenaar,
Chair, CEN TC 251; and Dr. Ed Hammond, Chair-elect, HL7 suggested the
three SDOs might be able to work jointly to produce a single global standard
for a single business purpose. After additional discussions, a charter was written
and was subsequently ratified by all three SDOs. The charter establishes a
Joint Initiative Council (JIC) that includes the chairs of the three participating
organizations plus two additional representatives from each SDO.
Figure 1 shows the global healthcare landscape. The JIC serves as a collaborative
forum for the international standards community. Within the US, the Federal
Health Architecture coordinates 55 Federal agencies. Vocabulary standards are
depicted in the oval boxes.
“The charter establishes a Joint
Initiative Council (JIC) that includes
the chairs of the three participating
organizations plus two additional
representatives from each SDO.”
NHS
Joint Initiative Council (JIC)
Infoway
NeHTA
CEN
HL7
ISO
CDISC
IHTSDO
IEEE
SCO
NCPDP
ASTM
ASC X12
SNOMED
HITSP
ANSI
CCHIT
NQF
FHA
ONC
NIST
LOINC
HIMSS/RSNA
MedDRA
ICH
CPT
AMA
ICD
WHO
IHE
HHS
NIH
FDA
VHA
NLM
CDC
DOD
NCI
CMS
Home Sec
DICOM
caBIG
US Realm
Figure 1: Global Healthcare Standards Landscape
Source: Health Level 7
The word “joint” initiative was chosen specifically to distinguish this activity
from harmonization, since harmonization was generally considered to be
efforts to map one standard to another competing standard. Any joint project
must be agreed to by this group. A Joint Working Group (JWG) was also
created, managed by ISO, which includes members from the participating
SDOs. The purpose of the JWG is to work through the details of any joint
initiative project, identify potential new projects, monitor the work on joint
initiative projects, and support, in general, the work of the JIC. Each JIC
project would be hosted by one of the participating SDOs, with that SDO
providing a project chair or lead for the project. Each of the other SDOs
would provide a co-chair to ensure the resulting work met the needs of each
participating SDO.
“Harmonization was generally
considered to be efforts to map one
standard to another competing
standard.”
The work on any project would be done jointly by volunteer members from
each participating SDO, working as a cohesive unit. The three SDOs would
be considered equal in the work process. The resulting work product would be
balloted simultaneously by each participating SDO, and the comments from
each SDO would be aggregated and processed by the joint project team. The
resulting standard would be the joint property of each participating SDO and
would carry a shared copyright and the logo of each SDO.
“ISO 21090: Healthcare Data Types,
was approved in 2009.”
The first, now successfully concluded, JIC project was a standard for data types.
This standard, ISO 21090: Healthcare Data Types, was approved in 2009, after
many years of unsuccessful work to bring disparate groups together. Other
projects, listed next, have been accepted as JIC projects:
•• Individual Case Safety Report
•• Glossary Project
•• 13606/HL7 version 3 Implementation Guide
•• Identification of Medicinal Products
•• Clinical Trial Registration and Result
•• BRIDG Data Model
There are a number of other items being proposed as JIC projects. Once the
scope and definition of a project is defined, and the participants begin to
establish a level of trust in one another and can work together, the projects do
move ahead.
“The JIC has developed a policy and
procedures for defining projects, for
governance, and for bringing other
groups into the JIC.”
The JIC has developed a policy and procedures for defining projects, for
governance, and for bringing other groups into the JIC. Since the creation
of the JIC by the three SDOs, two other SDOs have joined the group: the
Clinical Data Interchange Standards Consortium (CDISC) became a member
in 2008, and the International Health Terminology Standards Development
Organization (IHTSDO) became a member in 2009. Other SDOs are in the
process of joining the JIC.
There are barriers that still must be overcome for the JIC process to work. The
balloting scenario differs among the three SDOs. The length of the balloting
period differs as does the publication process and form. Communication
among the participating SDOs and their membership is very challenging.
Understanding the process has been difficult for all those involved, and
managing the process has also been a challenge.
“Understanding the process has been
The success of the JIC offers a lot of promise, however. In the United States, an
organization similar, at least in purpose to the JIC, has been formed: the SDO
Charter Organization (SCO). This organization promises to consolidate efforts
within the United States to produce a single standard for a single purpose.
Those involved are strongly motivated to work together for a number of
reasons. They can share expertise and resources, such as tools and repositories;
and working together makes more efficient use of limited funding. Moreover,
most SDOs recognize that the global market is expanding, and that there
is an urgent need to accelerate the development of standards to avoid both
marketplace and regulatory ambiguity. The more confusion, the less likely
players will be to use standards in the marketplace.
difficult for all those involved, and
managing the process has also been a
challenge.”
The Role of Architecture in Developing Healthcare
Interoperability Standards
In this section, we look at the role of architecture and an architectural
framework in developing healthcare interoperability standards, and we present
some example environments that use them.
HL7 is a set of standards that supports interoperability of software applications
that are designed to support clinical and administrative processes in a
healthcare organization. While any healthcare organization can use HL7’s
interoperability standards, these standards are, for the most part, designed for
use by healthcare provider organizations.
“While any healthcare organization
can use HL7’s interoperability
standards, these standards are, for
the most part, designed for use by
healthcare provider organizations.”
Simply put, the architecture of an interoperability standard is a high-level view
of the components that make up the standard and the relationships between
those components. An architecture framework, as discussed here, is a reference
context that we use to view each HL7 standard product and its components.
These useful analysis tools are new to HL7.
Over its 22 years, HL7 has both created new and adopted some existing
standards. Because of the separate and distinct origins of these standards, a
different architecture could have been written for the internal components and
their inter-relationships for HL7’s major standards products: these products
include the HL7 version 2.x; HL7 version 3.0; HL7’s EHR standards; CCOW;
and Arden Syntax. To begin this remedial effort of creating a common housing
to hold the architecture definitions of all HL7’s major products, HL7 created
an architectural framework called HL7’s Services Aware Enterprise Architecture
Framework (SAEAF).
We shall now provide a high-level introduction to HL7’s SAEAF. We view
SAEAF as it applies to the HL7 version 3.0 standards, including the major
components that they share (for example, the HL7 RIM), and the somewhat
different purposes that they serve. Our customers, including those working
in the UK, Canada, and now the United States, all begin their efforts with
provider organizations that use the different architectures of the HL7 version
2.x and the HL7 version 3.x products, that going forward must co-exist and
interoperate to achieve country-wide interoperability goals.
“To hold the architecture definitions
of all HL7’s major products, HL7
created an architectural framework
called HL7’s Services Aware Enterprise
Architecture Framework.”
HL7 and Architecture: a Brief Introduction
In 1987 the HL7 organization was created with the purpose of creating
interoperability standards for the exchange of electronic information between
IT systems within and between healthcare providers. Not surprisingly, the
technology, workflows, and systems architectures created by HL7 in 1987
were the ones in use by the information technology (IT) industry in 1987.
The standard created at that time (HL7 version 2.1) achieved widespread use,
starting in 1991 and has evolved through a series of major and minor updates
to HL7 2.6 today. No formal architecture was ever planned for any element of
the HL7 version 2.
“No formal architecture was ever
planned for any element of the HL7
version 2.”
About five years later, HL7 volunteers expressed an interest in and began
working on a RIM for healthcare. There were no formal expectations at the
time for the scope of the effort, the amount of time it would take, or even
the expected difficulty that we would encounter. This experience was quite
eye-opening, because it forced HL7 developers to document the vastness and
complexity of healthcare. Nevertheless, no formal architecture was defined for
any HL7 standard that uses the RIM, although the RIM itself did assume a
formal internal architecture that addresses its governance, definitions, and the
tools related to testing conformance.
“This experience was quite eyeopening, because it forced HL7
developers to document the vastness
and complexity of healthcare.”
The HL7 RIM was never intended to stand on its own — although as a
reference model of healthcare information, it certainly does. Once the RIM was
recognized as possible, the organization also turned to the effort of developing a
new standard for data interchange that would have these features:
1. Model-driven (i.e., all data items that can be exchanged or used to generate
messages, documents, or services have a place and are taken from the RIM
where cardinality and relationship(s) to other data are clearly defined.
2. It must be formally connected to a methodology that itself could be
instantiated into software tools, giving us the following potential:
a. Using software tools to manage, validate, assemble, and publish the
version 3 Standard’s products, including the eXtensible Markup
Language (XML) schemas that would be needed to hold the metadata of
the information being exchanged.
b. Automating the generation of interchange specifications and creating
an environment where two or more individuals working from the same
set of requirements could generate identical specifications that could be
measured against a similar, software-generated set of conformities.
“Messages support connections between
IT systems that are involved in
supporting a workflow.”
These features evolved into the goals of HL7 version 3, which was first
published in 2004. Our goals for HL7 version 3 have also evolved into
three distinct delivery mechanisms that can be used for a version 3-based
interchange. These delivery mechanisms are discussed next.
An interchange can be a message similar to an HL7 version 2 message.
version 3 messages today are produced in XML syntax. Messages support
connections between IT systems that are involved in supporting a workflow.
HL7 version 2 describes a workflow through a pre-defined and somewhat
vague descriptor called a “trigger event.” For example, within an institution, a
trigger event could be a physician’s lab order placed at the patient’s bedside to
the hospital pathology laboratory. This workflow may be clearly understood by
everyone involved in every possible action step required, from the composition
of the order to the reporting of the signed final test results to the assigned
individual. However, the same workflow within an ambulatory setting can be
far more difficult to describe, because the actors in the workflow do not have an
integrated understanding of each other’s role.
Most importantly, it is not ideal that we lack a formal behavioral model
(i.e., a dynamic or workflow model), but we compensate for this by analyzing
the existing workflow and then programming our interchange steps to
accommodate it. Secondly, we can only create different interchange patterns as
we encounter them. In both cases, a formal dynamic model could document
the supported workflow; assign a unique identifier to that workflow that could
be used by all parties; and serve as a base platform to be modified and re-used
when slightly new or different workflows are encountered.
“A formal dynamic model could be
modified and re-used when slightly
new or different workflows are
encountered.”
Messages have an expected lifetime bound by the instant in time that they are
created and used. A message has no further use once the content of a message
is consumed by the target system and optionally used to change the state of
its database. Hypothetically, a message might be used as a possible means of
assisting in a database recovery action, something that, hopefully, is never
needed.
The next delivery mechanism is Clinical Documents, based on the HL7
Clinical Document Architecture (CDA) standard, which is a part of HL7
version 3, and which shares and uses the same underlying artifacts (for
example, HL7 RIM, R-MIMS, Data Types, etc.). Clinical Document
templates are implementation guides based on the CDA. Clinical Documents
contain structured clinical data that also conform to document requirements
of being signed (electronically), immutable, and so forth. Documents may
indirectly be the product of and/or support a workflow, but they stand on their
own and typically have an indefinite life.
“Clinical Documents contain
structured clinical data that also
conform to document requirements
of being signed (electronically),
immutable, and so forth.”
The third delivery mechanism is a service that is based on the SAEAF. This
mechanism (as messages and documents) will be defined by the relevant HL7
Work Group responsible for the interchange’s content (for example, Structured
Documents for CDA). In HL7, services are currently based on the principles of
a Services Oriented Architecture (SOA) that is, itself, based on the antecedent
concepts developed in the Referent Model of Open Distributed Processing
(RM-ODP).
“This mechanism (as messages and
documents) will be defined by the
relevant HL7 Work Group responsible
for the interchange’s content (for
example, Structured Documents for
CDA).”
HL7’s Services-Aware Enterprise Architecture Framework
SAEAF was created by the HL7 Architecture Board (ArB) as a response to
a request from the CTO for an HL7 architecture that is driven by HL7’s
commitment to the following three principles:
1. HL7 produces specifications to enable Computable Semantic
Interoperability (CSI) between users of systems implementing those
specifications.
2. Instances of CSI between two or more HL7-based systems may cross
department, enterprise, and/or national boundaries.
3. An HL7 Enterprise Architecture Specification (EAS) is required, if HL7 is
to produce durable specifications that enable CSI in an effective, efficient,
and scalable manner.
The ArB recognized early on that three critical components were missing from
HL7 and, therefore, they needed to develop SAEAF. These are the missing
components:
1. A Behavioral Framework to express interaction semantics.
2. A layered Enterprise Conformance/Compliance Framework (ECCF) to
support service integration and run-time assessment of CSI.
3. A Governance Framework to oversee the development and implementation
of service (and other HL7 Interoperability Paradigm) specifications.
Computable Semantic Interoperability (CSI)
In order to understand the aforementioned, it is necessary to understand a little
of what HL7 sees as the requirements to achieve CSI. These necessary, but not
inclusive, requirements include the following:
1. Common static models (for example, the HL7 RIM) across all domains of
interest including:
a. An information model versus a data model.
b. The semantics of common structures.
c. Models based on robust data-type specifications.
2. A mutually understood behavioral (or dynamic) model that enables
sufficient (as defined by the problem space) understanding of the “use
context” of the creation of the data by the producer and its intended use by
the consumer.
3. Methodology for binding to concept-based ontologies that support these
constraints:
a. Domain-specific semantics.
b. Country, regional, or use-domain selection of appropriate ontologies.
c. Rigorous versioning release cycle management to ensure that individual
terminologies are consistently interpreted by both the producer and
consumer of the data.
4. A formally-defined process for specifying structures that contain both
data and defined actions to be exchanged between machines, i.e., a data
exchange (such as a message or a service) or an electronic document or
services specification.
Looking at the first three requirements of CSI just outlined, it is useful
to understand them as the dimensions of variability for any data element
exchanged between two HIT systems. As Figure 2 illustrates, three properties
must be defined to exchange data elements: the data, terminology, and process
or behavior. Taken together, these three dimensions provide a context for
the information to be shared. We need to know data type (e.g., integer, text,
image), terminology (i.e., the specific ontology being used), and process or
behavior (e.g., a diagnostic process).
These three requirements, in addition to the fourth requirement of actually
moving the data, are necessary for CSI. Figure 2 depicts this.
Process/Behavior
P
(D,P,T)
D
T
Data
Terminology
Figure 2: Information Context for Data Elements
Summary and Next Steps
HL7 has begun the effort of defining an architectural framework called SAEAF
that is both accommodating of services-based interoperability in an SOA and
capable of providing a framework for holding, comparing, and analyzing the
similarities and differences among HL7’s products. Going forward, SAEAF is
also the basis for EAS that will be used in the future to apply HL7 to user SOA
environments.
In our next section, we move on to describe the HL7 CDA, and we examine its
role in healthcare in the United States today.
“HL7 is also developing standards
for the representation of clinical
documents (such as discharge
summaries and progress notes).”
The Templated CDA Strategy: Scalable and
Incremental Interoperability
Many people know of HL7 as an organization that creates healthcare messaging
standards. HL7 is also developing standards for the representation of clinical
documents (such as discharge summaries and progress notes). These document
standards make up the HL7 clinical document architecture (CDA). The HL7
CDA, Release 1, became an ANSI-approved HL7 standard in November 2000.
CDA Release 2 became an ANSI-approved HL7 standard in May 2005, and it
is now in widespread use across the globe.
What follows is an introduction and overview of the CDA specification,
along with a description of how and why CDA has emerged as a cornerstone
component of the United States healthcare interoperability strategy.
“Approximately 1.2 billion clinical
documents are produced in the
United States each year. Dictated
and transcribed documents make
up around 60 percent of all clinical
notes.”
“Our goal is to get at the clinical
content within those documents and
make it computable, accessible to a
The need for a clinical document standard stems from the desire to unlock
the considerable clinical content currently stored in free-text clinical notes,
and to enable comparison of that content in documents created on widely
different information systems. Approximately 1.2 billion clinical documents are
produced in the United States each year. Dictated and transcribed documents
make up around 60 percent of all clinical notes. These documents contain the
majority of physician-attested information and are used as the primary source
of information for reimbursement and proof of service.
The challenge, addressed by CDA and the templated CDA strategy, is to
continue to meet the needs of front-line clinicians today, who are heavily
dependent on largely narrative documents, while at the same time providing
a migration pathway for greater and greater discrete data. In other words, the
goal of CDA is not simply to provide yet another format for the exchange of
clinical documents. If that were all we wanted, we could use PDF, MS Word*,
or any other file format. Instead, our goal is to get at the clinical content
within those documents and make it computable, accessible to a computer, so
it can be used for such things as decision support and quality reporting. We
want to do this in a way that fits in to real-world clinical workflows so that we
can tackle the problem incrementally, without the need for massive process
redesign.
From a technical perspective, the HL7 CDA is a document markup standard
that specifies the structure and semantics of a clinical document. A CDA
document is a defined and complete information object that can exist outside
of a message, and it can include text, images, sounds, and other multimedia
content. Just as you can create a document in MS Word, in PDF, etc., you can
create a clinical document in CDA format. CDA documents are encoded in
XML and derive their machine processable meaning from the HL7 RIM.
computer, so it can be used for such
things as decision support and quality
reporting.”
CDA is based on a principle of incremental interoperability, whereby an
implementer can begin with a simple CDA, and then add structured data
elements over time. CDA R2 consists of a single CDA XML schema, and
the architecture arises from the ability to apply one or more templates that
serve to constrain the richness and flexibility of CDA. Professional society
recommendations, national clinical practice guidelines, and standardized data
sets can be expressed as CDA templates.
“All CDA documents must use the
same narrative markup so that you
can receive a CDA document from
anyone in the world.”
From a practical perspective, incremental interoperability means that one can
easily create a minimally-conformant CDA document — not really much
different than creating an HTML document. CDA documents have a header
that identifies and classifies the document and provides information on
authentication, the encounter, the patient, etc. There are a handful of required
fields and a number of optional fields. The body of the CDA can be purely
narrative, by using markup very similar to XHTML. All CDA documents must
use the same narrative markup so that you can receive a CDA document from
anyone in the world, and, following a defined algorithm, render the document
such that the receiving clinician correctly views content that was attested to by
the originating clinician.
In addition to its narrative markup, CDA provides XML markup for formally
representing the clinical statements within the narrative. A complete encoding
of all clinical utterances can be hard if not impossible, and there is no model
of healthcare that can fully and formally represent everything a clinician
might say. While the HL7 RIM is a richly expressive model that can represent
much of clinical narrative, the templated CDA strategy shields developers from
the need to learn all the RIM nuances. Developers only need to understand
those templates that have been recommended by the Healthcare Information
Technology Standards Panel (HITSP) or put on the Certification Commission
for Healthcare IT (CCHIT) roadmap. Developers simply map their internal
data stores to the prioritized templates.
Assume that next year, HITSP defines the way in which we should
communicate medical conditions and allergies. Assume that CCHIT takes
these HITSP patterns and creates corresponding certification requirements. For
those using CDA, there is no need to change to a new XML schema, and there
is no need to change the approach to communicating narrative notes. CDA
templates for medical conditions and allergies are created. An application maps
their internal data stores to these templates, and it includes corresponding
structured markup for medical conditions and allergies into CDA, whilst
making no change to the narrative. On the recipient side, there will continue
to be those who only render the document, whereas there may also be those
who can parse out the formally encoded medical conditions and allergies for
use in decision support, disease management, personalized medicine, and
many other critical healthcare delivery requirements. Figure 3 shows the CDA
constrained by the data elements of the Continuity of Care Record (CCR, in
red) named the Continuity of Care Document (CCD). In this example, the
CDA template includes additional data elements not found in the CCR (such
as Chief Complaint and Discharge Diagnosis).
“CDA provides XML markup for
formally representing the clinical
statements within the narrative.”
“For those using CDA, there is no
need to change to a new XML schema,
and there is no need to change the
approach to communicating narrative
notes.”
Clinical Document Architecture
Continuity of Care Document
Allergies
Problems
Meds
Personal Information
Insurance
…
YYYY
Narative and tabular
XXX
Narative
TTTT
ZZZZ
Narative
Mode of transport
Discharge Diagnosis
Chief Complaint
Figure 3: CDA constrained by Additional Data
Elements
Next year, HITSP and CCHIT will prioritize new templates; the following year
more templates will be produced, and so it goes — scalability arises from the
fact that one XML schema does it all; incrementalism arises from the fact that
only well-described changes need to be introduced over time, on a defined
roadmap.
CDA is attractive for these reasons:
•• Scope. There is a single XML schema for all CDA documents.
•• Implementation experience. CDA has been a normative standard since 2000,
and it has been balloted through HL7’s consensus process. CDA is also
widely implemented.
•• Gentle on-ramp to information exchange. CDA is straight-forward to
implement, and it provides a mechanism for incremental semantic
interoperability. One can begin with a simple CDA narrative document
implementation and add discrete data elements over time, based on
national priorities.
•• Improved patient care. CDA provides a mechanism for inserting evidencebased medicine directly into the process of care (via templates), thereby
enabling the application of evidence-based medicine.
•• Lower costs. CDA’s top-down strategy lets you implement CDA once, and
reuse it many times for new scenarios.
These attributes of CDA have lead to its adoption as a core healthcare
information technology component in many countries, including the United
States, in particular by HITSP. Interoperability on a use-case by use-case basis
can lead to a disjointed set of standards that do not support re-use or internal
consistency. What is needed is an overarching approach to interoperability, one
that is both widely encompassing and scalable, as new use cases are developed.
A strategy being exploited by HITSP, as well as the Integrating the Healthcare
Enterprise (IHE) and other international HIT initiatives, is to base a growing
number of Interoperability Specifications (ISs) on the CDA, or, more
precisely, on templated CDA. From its inception, CDA has supported the
ability to represent professional society recommendations, national clinical
practice guidelines, and standardized data sets as “templates” or constraints
on the generic CDA XML. Perhaps the best known example of a templated
CDA specification is the ASTM/HL7 Continuity of Care Document (CCD)
specification (see Figure 4), where the standardized data set defined by the
ASTM Continuity of Care Record (CCR) is used to further constrain CDA,
specifically for summary documents.
“What is needed is an overarching
approach to interoperability, one
that is both widely encompassing
and scalable, as new use cases are
developed.”
Subsequent to its adoption of CCD as the basis for HITSP/C32 “Summary
Documents using HL7 CCD,” HITSP recognized that a top-down strategy,
whereby one learns CDA once and then re-uses it in other ISs, leads to greater
cross use-case consistency. HITSP has since created a library of CDA templates
(HITSP/C83 “CDA Modules Component”) that are used within a growing
number of CDA-based specifications (for example, HITSP/C28 “Emergency
Care Summary,” HITSP/C32 “Summary Documents Using HL7 CCD,”
HITSP/C105 “Patient Level Quality Data Document Using HL7 Quality
Reporting Document Architecture (QRDA),” HITSP/C48 “Encounter
Document constructs,” HITSP/C84 “Consult and History & Physical Note
Document,” and HITSP/C78 “Immunization Document”).
Clinical Document Architecture
Continuity of Care Document
Problems
Meds
Personal Information
Insurance
…
Additional templated CDA specifications being developed within IHE and
HL7 include the QRDA, the Public Health Case Report Document, Operative
Reports, Personal Health Monitoring Reports, and Minimum Data Set,
version 3. What is true across the spectrum of specifications is that all the
specifications conform to the underlying CDA XML, and templates are re-used
to the extent possible. CDA, coupled with a library of re-usable templates,
forms the basis for a growing number of HITSP ISs, and CDA represents a
national interoperability strategy that is both widely encompassing and scalable
as new use-cases are developed.
Considerable discussion is taking place now in the United States around
the notion of meaningful use, and about ensuring that our interoperability
strategy supports meaningful use. At the heart of meaningful use is simply a
requirement for data re-use as in re-using clinical trial data in the construction
of decision support rules, re-using clinician-captured data for quality reporting,
public health reporting, etc. Imagine, for instance, that there were separate
models and XML schemas for immunization data, medication administration,
pharmacy dispensing, lab, and clinical summaries, and that the onus was on
the implementer to reconcile the differences in the data in order to support
data re-use. CDA and templated CDA address the concept of meaningful reuse, by maximizing data re-use.
Allergies
A CCD
based
document
YYYY
XXX
Narative
TTTT
ZZZZ
Narative
Mode of transport
Discharge Diagnosis
Chief Complaint
Figure 4: Templated CDA Specification
The value of the RIM, and the rationale for its use as the underlying formalism
for encoding clinical statements in a CDA document include the following:
•• Consensus. A consensus process is used in the development of the RIM that
encompasses many years, many vendors, many countries, and many usecases.
•• Expressivity. This allows for the formal representation of many types of
clinical statements.
•• Data re-use. All version 3 specifications are derived from a common model.
•• Concrete. While not perfect, RIM is here today for us to use.
•• Governance and maintenance. There is a defined consensus process for
revisions.
“CDA and templated CDA address
the concept of meaningful re-use, by
maximizing data re-use.”
“It is anticipated that several ballot
cycles will be required to work through
the list of new requirements, and
that CDA Release 3 will become
an ANSI-approved HL7 standard
sometime in 2011.”
CDA Release 1 became an ANSI approved HL7 standard in November 2000.
CDA Release 2 became an ANSI-approved HL7 standard in May 2005.
Balloting on CDA Release 3 is slated to begin towards the end of 2009. Given
that HL7 has three ballot cycles per year, and given the widespread adoption
of CDA Release 2, it is anticipated that several ballot cycles will be required
to work through the list of new requirements, and that CDA Release 3 will
become an ANSI-approved HL7 standard sometime in 2011. CDA Release 3
requirements are cataloged as formal proposals and as suggested enhancements.
The main feature enhancement expected for CDA Release 3 is the inclusion
of much more of the HL7 RIM, thereby enabling a wider range of clinician
narrative to be expressed.
Standards and Standards Development
Organizations: A New Collaboration
“Standards development is a
political process.”
Standards development is a political process. As described previously, the
stakeholders are diverse but not every interest is equally represented. In many
countries, the dominant voices in this process are the government agencies that
determine the business requirements and fund the development initiatives.
The other end of the spectrum is represented by the vendor community
that has always made a substantive contribution to the definition of the
standards’ artifacts. In the past, the caregiver community has been significantly
disenfranchised.
That is not to say that credentialed professionals have not been leaders of
standards development organizations and government agencies. Even when
clinicians lead these organizations, however, decision-making processes are
often blunted by layers of administrative bureaucracy and regulatory overhead.
Within the healthcare IT community, the chief medical information officer has
often provided critical guidance and commanded substantive influence.
There is a growing body of critical data and published studies that describe the
successful deployment of large-scale IT solutions within multi-disciplinary,
healthcare systems. In fact, the application of eHealth processes has been
shown to be transformative in various large, healthcare provider organizations.
Unfortunately, recent exposés in the public media have recounted instances of
dire unintended consequences of new or updated healthcare IT solutions. More
often than not, the problem with these installations has not been technical. The
apparent proximal cause has been the significant failure by system designers
and software developers to understand the workflow and daily business
requirements of the clinical end-users.
“The application of eHealth processes
has been shown to be transformative
in various large, healthcare provider
organizations.”
At the technical end of the implementation spectrum lies the need to ensure
seamless, unambiguous interchange of data. The inability to achieve this is
rarely the failure of the technical standards (specifications) themselves. Often
there is a lack of formal agreement on vocabulary, the definition of individual
data elements, and the application of the required terminology within the
patient care continuum. This is exacerbated when requests are made or
requirements defined across clinical boundaries. In simple terms, a physical
therapist may not apply the same meaning to a term as the orthopedic surgeon
who first used it. In the in-patient setting, this is repeated daily in a failure to
achieve unambiguous communication between physicians, nurses, pharmacists,
and laboratory staff.
“In simple terms, a physical therapist
may not apply the same meaning to
a term as the orthopedic surgeon who
first used it.”
Attempts to rectify these ambiguities have often failed to overcome parochial
and economic hurdles. In a practical sense, there is an ongoing tension among
primary caregivers and the specialist community. The gatekeeper model
of the managed healthcare system failed to achieve either fiscal or clinical
outcome metrics because of the dissension that was exacerbated when practice
variability was confronted with ambiguous, often counter-productive payment
schema. In those managed care systems with closed practice systems and a
single information system (e.g., Kaiser Permanente), the results are uniformly
significantly more successful.
Outside of the United States, stringent government regulation has often led
to improved outcomes following implementation of enhanced healthcare
information systems. Perhaps this is more related to a single payer system and a
more homogeneous patient population than to the technology itself. At times,
regulatory oversight has been an enormous obstacle to data interchange. For
example, the global regulated research community (chiefly pharmaceutical
and biotech industry) has embraced a structured vocabulary called the
Medical Dictionary for Regulatory Activities (MedDRA). This terminology
is principally required for data encoding in the reporting of adverse events in
clinical trials and in post-approval pharmacovigilance. The system is largely
incompatible with SNOMED CT (Systematized Nomenclature of Medicine
— Clinical Terms), which is in widespread use for patient care worldwide.
Both clinical research and patient care suffer because of the artificial barriers to
effective information exchange.
These problems transcend the functional requirements for interoperability.
For our purposes, it is best to rely on the definition established by IEEE.
Interoperability is the ability of two or more systems or components to
exchange information. Semantic interoperability is the ability to use the
information that has been exchanged. Faxing an EKG tracing between two
professional offices provides a high degree of interoperability, if both clinicians
agree on the parameters to use for interpretation. Like most data that are not
encoded, the EKG cannot be re-used in any meaningful way. Parenthetically,
HL7 has developed a standard for encoding an annotated EKG.
“Outside of the United States,
stringent government regulation
has often led to improved outcomes
following implementation of enhanced
healthcare information systems.”
“Interoperability is the ability of
two or more systems or components
to exchange information. Semantic
interoperability is the ability to use the
information that has been exchanged.”
“These practice guidelines are
predicated on more data being derived
from clinical research and have been
referred to as evidence-based
medicine.”
“The development of treatment
algorithms that weigh the relative
severity (importance) of two co‑morbid
diseases is the foundation for ongoing
research.”
Reducing the ambiguity of the data is increasingly important as healthcare
managers and researchers attempt to measure quality. For our purposes, the
enhanced clinical quality and patient-care outcomes are realized when practice
guidelines are adhered to by individual caregivers and system-wide care
requirements. Usually these guidelines are established by central authorities
(such as the US National Institutes of Health) and by professional societies
(for example, the American College of Cardiology). Globally, quality estimates
(outcomes) are provided by the World Health Organization.
In the United States, these guidelines have been historically written by the
Agency for Healthcare Research and Quality (AHRQ), an agency of the
Department of Health and Human Services. More recently, non-profit
organizations, such as the National Quality Forum, have been created to take a
more proactive role in writing these guidelines. These groups establish priorities
for quality evaluation as well as establishing the parameters for measuring
success. These practice guidelines are predicated on more data being derived
from clinical research and have been referred to as evidence-based medicine.
These guidelines are critical to improving patient outcomes and reducing costs.
Unfortunately, the clinical guideline for one disease may be contraindicated
when complying with the guideline for a co-morbid disease. For example,
the use of a relatively common anti-inflammatory drug for arthritis, such
as ibuprofen, may be contraindicated in the management of hypertension.
These two ailments are often concurrent in the Medicare-aged population, but
practice management algorithms would indicate a violation of quality patient
care. The development of treatment algorithms that weigh the relative severity
(importance) of two co-morbid diseases is the foundation for ongoing research.
Other instances of conflicts of standard practice guidelines are less easily
resolved. These conflicts may represent the differences in the interpretation
of medical evidence between two medical societies or the same specialty in
different regions or countries. It is easy to imagine that the recommendations
offered by the American Academy of Orthopedic Surgeons would not coincide
with those of the American Chiropractic Association. HL7 is working closely
with the National Quality Forum and the Agency for Healthcare Research and
Quality to standardize these metrics.
“Decision support systems are highly
complex, predicated on the integration
of a vast amount of patient care
and research data, and reliant upon
the harmonization of technical
standards.”
Delivering evidence-based medicine at the point of care (inpatient, ambulatory,
emergent, or chronic home care) is enabled by a technology that is broadly
classified as decision support. Decision support systems are highly complex,
predicated on the integration of a vast amount of patient care and research
data, and reliant upon the harmonization of technical standards. Within
HL7, the Decision Support Working Group has advanced the technical
functionality of these systems. Practical implementation is more complex.
Individual system vendors have implemented decision support by using a vast
array of technologies, alerts, graphical interface representations, and workflow
modification. At the most simple level, this technology may be implemented
in the form of a clinical alert, for example, when two drugs with a potential for
adverse interaction are prescribed concurrently. Another example of decision
support might be a recommendation for an annual PAP smear at the time
of an outpatient visit. The most sophisticated systems guide complex disease
management and require data from lab testing and medication administration,
as in guidance for insulin dosing. HL7 is working closely with several decision
support initiatives, such as the Clinical Decision Support Consortium.
“HL7 is working closely with several
decision support initiatives.”
The most innovative program does not directly involve the development of
standards. It is an initiative in social engineering. Nearly four years ago, HL7
undertook a program for including specific clinical input into the standards
development process. This Work Group recognized the contributions of a
wide range of members of the caregiver community, including physicians,
nurses, pharmacists, and even medical librarians. While important progress
was made towards the identification of critical development pathways, the
Work Group sorely lacked a focus on patient care, public health, and program
management. In 2008, HL7 recognized the immediate need to align with the
caregiver communities. With funding from the AHRQ, an experiment was first
undertaken. The experiment went by the name of Bridging the Chasm.
At first blush, the chasm to be bridged was between the healthcare community
and the organization of healthcare IT professionals. It was most evident to the
clinicians that everyone was speaking a different language, filled with technospeak, jargon, and acronyms, with which they were embarrassingly unfamiliar.
Moreover, concepts, such as knowledge representation, so commonplace in
IT, were lost on the clinicians. To re-purpose an old adage, “the clinicians
were mad and they weren’t going to take it anymore.” Of course, there was
another, much older, and often more acrimonious divide to bridge. That was
the divisions erected over hundreds of years between specialists and primary
care physicians, between physicians and nurses (you can substitute almost any
other caregiver function), and between many of the ancillary but critical roles
of pharmacist, dietician, physical therapist, pathologist, and many others.
In April 2009, a conference was convened in Washington to begin the bridge
building. Funded by AHRQ and led by HL7, over 100 professional societies
met with one objective in mind: begin to define the terminology, workflow
processes, business requirements, and the like that everyone had in common.
Of course, standards development was to be a collateral outcome, but only
after the difficult task of bridge building was underway. This was not about
fence mending, since it was hoped that the fences would be torn down
eventually. For two days there was no jargon. Not an acronym was uttered. The
results were unprecedented, because this heterogeneous body moved forward
with unanimity of purpose.
“In 2008, HL7 recognized the
immediate need to align with the
caregiver communities.”
“Standards development was to be a
collateral outcome, but only after the
difficult task of bridge building was
underway.”
“In the office setting, in the home,
and in the hospital, the patients will
be the beneficiaries.”
With the creation of a new professional society, the Clinical Information
Interchange Collaborative, development of common terminology seems
possible. Integration of workflow into eHealth systems seems achievable.
Articulating a business case for the harmonization of practice parameters and
clinical guidelines has begun. In the office setting, in the home, and in the
hospital, the patients will be the beneficiaries.
Standards development for healthcare will always be about politics. The
problems to be solved have and will always have highly technical solutions.
Interoperability is not a goal, but rather the means to improving quality and
reducing costs. Creating innovative solutions to complicated issues of unified
vocabulary and seamless data integration can be realized in an environment of
collaboration.
Further Reading
Blobel, Bernd. “Making hospital IT interoperable.” HITE 2008:1:2: Summer
2008:12-15. Available at www.hospitaliteurope.com
Clinical Data Interchange Standards Consortium (CDISC)
This website contains standards and policy documents cited in this article.
http://cdisc.org/
Hammond, William Edward; Jaffe, Charles; Kush, Rebecca Daniels,
“Healthcare Standards Development: The Value of Nurturing Collaboration”
Journal of AHIMA, July 2009 80/7, pages 44-40.
Health Level Seven, Inc.
www.hl7.org
On the website can be found more detailed supporting material cited in this
article:
CDA Tutorial, 2008.
HL7 version 2.5 and HL7 2.6 Standards.
Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A.
“HL7 Clinical Document Architecture, Release 2.” J Am Med Inform Assoc.
2006;13:30–39. Available at www.jamia.org.
HITSP/C32: “Summary Documents Using HL7 Continuity of Care
Document (CCD); Component.” July 8, 2009. Version 2.5.
HITSP/C37: Lab Report Document Component. July 8, 2009. Version 2.3.
HITSP/C75: Healthcare Associated Infection (HAI) Report Component.
July 8, 2009. Version 1.1.
HITSP/C83: CDA Content Modules Component. July 8, 2009. Version 1.1.
HITSP/C105: Patient Level Quality Data Document Using HL7 Quality
Reporting Document Architecture (QRDA). June 30, 2009. Version 0.0.1.
European Committee for Standardization (CEN) Technical Committee 251
(Healthcare)
This site contains standards and policy information cites in this article.
http://www.cen.eu/cenorm/sectors/sectors/isss/index.asp
ISO Technical Committee 215 (Healthcare Informatics)
This workspace contains documents and standards cited in this article:
http://isotc.iso.org/livelink/livelink?func=ll&objId=529137&objAction=browse
Acronyms
Agency for Healthcare Research & Quality (AHRQ)
American National Standards Institute (ANSI)
Association Française de Normalisation (AFNOR)
British Standards Institution (BSI)
Certification Commission for Healthcare IT (CCHIT)
Clinical Data Interchange Standards Consortium (CDISC)
Clinical Document Architecture (CDA)
Comité Européen de Normalisation (CEN)
Computable Semantic Interoperability (CSI)
Continuity of Care Document (CCD)
Continuity of Care Record (CCR)
Enterprise Architecture Specification (EAS)
Enterprise Conformance/Compliance Framework (ECCF)
Extensible Markup Language (XML)
German Institute for Standardization (DIN)
Health Level Seven (HL7)
Healthcare Information Technology Standards Panel (HITSP)
Integrating the Healthcare Enterprise (IHE)
International Health Terminology Standards Development Organization
(IHTSDO)
International Standards Organization (ISO)
Interoperability Specifications (ISs)
Joint Initiative Council (JIC)
Quality Reporting Document Architecture (QRDA)
Reference Information Model (RIM)
Referent Model of Open Distributed Processing (RM-ODP)
Services Aware Enterprise Architecture Framework (SAEAF)
Standards Developing Organization (SDO)
SDO Charter Organization (SCO)
Services Oriented Architecture (SOA)
Author Biographies
Charles Jaffe, MD, PhD, FACP. Since 2007, Dr. Jaffe has served as the Chief
Executive Officer of HL7. He began his career at Intel in 2005 as the Senior
Global Strategist for the Digital Health Group. He has also served as Vice
President of Life Sciences at SAIC and as the Global Director of Medical
Informatics at AstraZeneca Pharmaceuticals. He completed his medical
training at Johns Hopkins and Duke Universities, and he was a post-doctoral
fellow at the National Institutes of Health and at Georgetown University.
Formerly, he was President of InforMed, a consulting firm for research
informatics. Over his career, he has been the principal investigator for more
than 200 clinical trials, and he has served in various leadership roles in the
American Medical Informatics Association. He has been a board member on
leading organizations for information technology standards, and he served
as the Chair of a national institutional review board. Currently, he holds an
appointment in the Department of Medicine at the University of California at
San Diego. He has been the contributing editor for several journals and he has
published on a range of subjects, including clinical management, informatics
deployment, and healthcare policy.
W. Ed Hammond, PhD, is Professor-emeritus, Department of Community
and Family Medicine and Professor-emeritus, Department of Biomedical
Engineering, Duke University and Adjunct Professor in the Fuqua School
of Business at Duke University. He has served as President of the American
Medical Informatics Association (AMIA), President of the American College
of Medical Informatics, and as Chair of the Computer-based Patient Record
Institute. He is currently serving his third term as the Chair of HL7. He was
Chair of the Data Standards Work Group of the Connecting for Health PublicPrivate Consortium. Dr. Hammond was a member of the IOM Committee
on Patient Safety Data Standards. He was awarded the Paul Ellwood Lifetime
Achievement Award in 2003 and the ACMI Morris F. Collen Award of
Excellence in November 2003.
John Quinn is the Chief Technology Officer of HL7 and has served in
this full-time position since September 2007. HL7 is one of several ANSI
-accredited SDOs operating in the healthcare arena.
Quinn is also a Senior Executive, Chief Technology Officer and Thought
Leader in Accenture’s Health Life Science’s Provider Practice focusing on
healthcare information system’s technologies, architectures, and data and
messaging standards; and he serves in his role as HL7’s CTO in part through
a significant contribution by Accenture. He has over 32 years experience in
Healthcare IT and 35 years experience in computer industries, respectively. He
has participated on the HL7 Board of Directors since its inception 21 years ago
and served as the Chair of its Technical Steering Committee from 1989–2007.
Robert H. Dolin, MD, MS, serves as the Chair-elect on the HL7 Board of
Directors and has been involved with the organization since 1996. Dr. Dolin
is an internationally renowned and innovative physician expert in healthcare
information technology standards development with more than 20 years
of clinical experience. After receiving his medical degree, he served as chief
resident at UCLA Department of Medicine in 1989, where he developed
Harbor-UCLA first outpatient electronic medical record system. Dr. Dolin
is a Fellow in the American College of Physicians, and he was elected into
Fellowship in the American College of Medical Informatics in recognition of
his work on standards development. Dr. Dolin currently owns Semantically
Yours, a healthcare standards consulting firm. Previously, he spent 18 years
as a Hospitalist at Kaiser Permanente, Department of Internal Medicine. At
Kaiser, he was the physician lead for the enterprise terminology services team,
responsible for deploying SNOMED in their national electronic health record.
Dr. Dolin also co-chairs the HL7 Structured Documents Work Group, and
is co-editor of the HL7 CDA and the CCD specifications. He has also served
on the SNOMED CT Content Committee, and currently co-chairs the US
HITSP Foundations Committee. Dr. Dolin’s work has also been published in
both technical and clinical peer reviewed journals.
Copyright
countries.
Healthcare Information Integration: Considerations for
Remote Patient Monitoring
Contributors
Kristina M. Kermanshahche
Intel Corporation
Index Words
Remote Patient Monitoring (RPM)
Semantic Interoperability
Service Oriented Architecture (SOA)
Healthcare Informatics
Chronic Disease Management (CDM)
HL7 Clinical Document Architecture (CDA)
Abstract
Modern healthcare is no longer practicable without data integration. Without
standards, integration costs soar and threaten the effectiveness of healthcare
delivery. With standards, information becomes accessible in computable
form, driving new levels of clinical research, patient-empowered healthcare,
and innovative business models. In this article we examine a few of the latest
developments in healthcare informatics standards with respect to remote
patient monitoring, review recent learnings in deploying a remote patient
monitoring solution, and identify key considerations and areas for further
development.
Introduction
Simple interventions can save lives and reduce the cost of healthcare. Home
care for patients with co-morbidities can mean the difference between life and
death. For example, with ongoing monitoring of vital signs, patient condition,
and medication levels, sudden changes outside of the patient’s established
thresholds can be detected, which can mean the difference between extended
hospitalization and rapid decline in health, versus maintaining a quality of life
in the patient’s home, surrounded by family and friends.
Similarly, maintaining tight control over blood glucose levels during gestational
diabetes can mean the difference between premature birth with a whole host
of medical complications for both mother and child, versus a stable healthy
maternity and normal delivery.
“Home care for patients with
RPM can be significant to both examples just cited, and the effectiveness
of RPM depends directly on the availability of standardized information
from a variety of healthcare data sources, including patient health summary,
prescriptions, lab results, daily vital signs collection, and functional
assessments.
co‑morbidities can mean the difference
between life and death.”
80 | Healthcare Information Integration: Considerations for Remote Patient Monitoring
We first explore the standardized representation of RPM information by using
the Health Level 7 (HL7) v3 CDA Release 2 [4] and the Personal Health
Monitoring Report (PHMR) Draft Standard for Trial Use (DSTU) [10]. Then,
we consider recent developments with the American Health Information
Community (AHIC) Use Cases and Healthcare Information Technology
Standards Panel (HITSP) Implementation Guides for Remote Patient
Monitoring [6, 7], Consultation and Transfer of Care [5], Long-Term Care
Assessments [13], and the resulting HL7 Implementation Guide for CDA 2:
CDA Framework for Questionnaire Assessments DSTU [8]. We review several
SOA principles and considerations critical to healthcare integration. Next,
we discuss several technical and workflow considerations when designing and
deploying a RPM solution. Along the way we identify multiple areas suitable
for further development.
Founded in 1987, Health Level Seven (HL7)
is a not-for-profit, ANSI-accredited standards
development organization dedicated to
providing a comprehensive framework and
related standards for the exchange, integration,
sharing, and retrieval of electronic health
information that supports clinical practice and
the management, delivery, and evaluation of
health services.
Remote Patient Monitoring Use Case
In this section we discuss a typical RPM use case, in order to set the context for
applying healthcare informatics standards and to explain how subtle nuances
in clinical workflow and system interactions can have a profound impact, both
on the design of the end-to-end information integration as well as on future
enhancements to informatics standards.
The sequence diagram depicted in Figure 1 was adapted from the HITSP
RMON Business Use Case [6], representing a superset of actors, steps, and
functionality across a number of finer-grained but related use cases. We
currently work with clinicians in a variety of regions worldwide but primarily
based in the United States and the United Kingdom. Clinical delivery and
reimbursement models are very different between these two regions. Some
healthcare delivery models rely upon visiting nurses, community outreach,
and clinical call centers to perform primary patient engagement, monitoring
patients remotely and within the home, and only referring the most acute cases
for physician or hospital intervention.
Other delivery models rely upon physician practices to monitor patients
directly, at times delegating these tasks to trained staff that operate as part of
the practice under their clinical supervision. These two models exist in both
regions regardless of patient acuity, frequency of monitoring, or reimbursement
models. (In the healthcare context, patient acuity refers to the type and severity
of illness, with acutely ill patients requiring emergency care.) It is important
that use cases and the supporting informatics standards comprehend these
types of variation in order to deliver an effective RPM solution.
AHIC is a federal advisory body, chartered in
2005 to make recommendations to the Secretary
of the U.S. Department of Health and Human
Services on how to accelerate the development
and adoption of health information technology.
AHIC specifies prioritized healthcare use
cases, for which the HITSP then develops
interoperability specifications, leveraging,
harmonizing, and further constraining existing
internationally-recognized standards. HITSP
identifies gaps in coverage and forwards new
development areas to Standards Development
Organizations (SDOs) for consideration
in future revisions. While both AHIC and
HITSP are entirely U.S.-centric in focus,
similar organizations exist in each major region
worldwide and their common goal is to achieve
standards harmonization. The process of
international standards harmonization is covered
separately in this issue by Jaffe, et al.
“We currently work with clinicians
in a variety of regions worldwide but
primarily based in the United States
and the United Kingdom.”
Healthcare Information Integration: Considerations for Remote Patient Monitoring | 81
Remote Monitoring
Management System
Electronic Health
Record (EHR) System
Patient
Event: Collection of Patient Session Data (vital signs, assessments)
according to prescribed Treatment Plan
Remote Monitoring Values Compared
Against Reference Range
Alerts and Notifications Generated for
Values Outside of Reference Range
Remote Monitoring Information
Transmitted to Clinician’s EHR
Clinician Reviews Remote
Monitoring Information from
Within the EHR
Updated Treatment Plan Transmitted
to Remote Monitoring System
Clinician Modifies
Treatment Plan as
Necessary
Updated Treatment Plan
Conveyed to Patient
Figure 1: RPM Sequence Diagram
Source: Intel Corporation, 2009. Adapted from HITSP RMON Business Sequence Diagrams [6]
Figure 1 represents three primary actors of concern – the Patient, the Remote
Monitoring Management System (RMMS) that operates the RPM solution,
and an external Electronic Health Record (EHR) system, which might
represent anything from a clinical electronic medical record system to a
purpose-built system developed specifically for chronic disease management
(CDM) or home health monitoring. The primary monitoring of a patient’s
wellbeing by a clinician can occur either within the RMMS itself or by
extension, from within the EHR system. The sequence diagram is triggered by
the event of patient data collection, including vital signs and assessments
defined by a treatment plan, which specifies not only what data to collect but
also the frequency and schedule.
“Patients work with a variety of
peripheral device types including blood
pressure cuff, glucose meters, weight
scales, and pulse oximeters.”
Typical patients are asked to collect vital signs anywhere from one to four times
per day (an average of eight vital sign readings per day), ranging anywhere
from three to seven days per week. Patients work with a variety of peripheral
device types including blood pressure cuff, glucose meters, weight scales,
and pulse oximeters. Vital sign measurements are combined with assessment
questions that are geared to assess patient adherence to the treatment plan,
functional status, and coping mechanisms with regard to their specific set of comorbidities, such as congestive heart failure, diabetes, and chronic obstructive
pulmonary disease (COPD).
Once the RMMS aggregates the vital sign and assessment data, it compares
the values against a pre-established reference range or threshold to identify
those readings that are out of normal range. Optionally, alerts and notifications
may be generated to the EHR system and members of the clinical team,
notifying them of the abnormal readings. Next, both normal and out-of-range
information is transmitted to the EHR system, either in raw or summary
format. The clinician reviews the information, makes clinical notes, and as
needed, generates referrals and modifies the treatment plan. The updated
treatment plan is transmitted to the RMMS and subsequently communicated
to the patient and the patient-local devices.
“Optionally, alerts and notifications
may be generated to the EHR system
and members of the clinical team,
notifying them of the abnormal
readings.”
The significance of the use case and sequence diagram just described are as
follows:
•• There is a high degree of variability in where patient data are maintained.
The clinician and clinical support team review and annotate patient
information in multiple systems of record. The RMMS is generally
deployed in addition to multiple legacy systems used to manage patient
healthcare, and typically, little to no integration exists.
•• Some healthcare use cases and informatics standards assume that a clinician
event is responsible for triggering the transfer of information from one
clinical team to the next; however, this use case underscores several
examples where data transmission is triggered instead by system events, and
it is important for informatics standards to comprehend both scenarios.
•• The type, frequency, and schedule of the information collected is also
highly variable, which must be comprehended by informatics and system
deployment designs alike. The more standardized the information, the
more it will drive machine computability, advanced analytics, and improved
healthcare at lower costs. However, informatics standards must always
balance the goal of perfect information requiring every data element,
with a pragmatic approach to incremental adoption, relying instead on
implementations to deliver best effort results in populating standard data
elements with carefully designed constraints.
•• A consistent, appropriately encoded specification of the treatment plan
is just as important as the data collection itself. Initial focus is rightfully
on capturing and transmitting RPM data, yet to truly measure patient
adherence and prognosis over time, we also need a consistent method to
specify the treatment plan in a semantically meaningful way.
Cloud Services:
Remote Patient Monitoring Solution Boundary
6
Remote Monitoring
Management System
1
Data
12
Personal Health
Monitoring Device
Patient
2
7
SOA Integration
Services
4
Data
Synchronization
Entity Identity Service
Controlled Terminology Service
Patient Consent Service
Rx, Lab Results
9
8
Data
11
Data
10
Electronic Health
Record (EHR) System
3
Clinician
5
Care Manager
Figure 2: RPM Interaction Diagram
Figure 2 reveals several additional deployment considerations with respect to
RPM. Step 1 represents the transmission of patient session data to the RMMS.
The RMMS aggregates trend information, compares vital signs against
reference ranges, and generates alerts and notifications. It has its own data
repository, consisting of historical patient treatment plans, reference ranges,
clinical notes, patient monitoring data, and customer-specific configuration
information. The RMMS is necessarily designed to be an online transaction
processing (OLTP) system, since its primary goal is to drive RPM in a highperformance, transaction-oriented manner.
Optionally, Step 2 and 3 depict a care manager who reviews the patient’s status
from within the RMMS. The care manager may modify the treatment plan
directly, or annotate the record and refer to a clinician for review and followup. The care manager may also play a key role in assessing the viability of the
data collected prior to escalation. For example, in the case of a very low weight
reading generating an alert, the care manager might confirm that the patient’s
grandson had in fact triggered the scale.
“The RMMS is necessarily designed to
be an OLTP system, since its primary
goal is to drive RPM in a highperformance, transaction-oriented
manner.”
Step 4 represents some form of data synchronization between the RMMS and
the Integration Services environment. The primary goal of the Integration
Services environment is rapid query, retrieval, translation, transformation, and
guaranteed delivery (push/pull) of healthcare information between a number of
participating entities (Step 5). Integration Services, therefore, are commonly a
mix of online analytic processing (OLAP) combined with logical mechanisms
of extract, transform, and load (ETL). Trend analysis and summarization may
also be performed at this stage. The Integration Services environment is best
developed according to SOA principles, largely due to the complexity and
number of end points, the variability of legacy and standard interfaces, and
the number of different workflows and external services required. We discuss
the rationale and benefits of applying SOA to RPM in more detail later. The
mechanism of data synchronization depends upon patient acuity, data latency,
and a number of other considerations, also discussed later in this article.
As a part of the transformation that occurs in Step 5, multiple calls may be
made to services across the Internet (Steps 6 and 7) in order to complete the
healthcare dataset, including identity match; terminology encoding; record
locate; patient consent; or data enrichment, incorporating the latest lab results,
prescription history, or drug-to-drug interaction checks.
Finally, the RPM information is transmitted to the EHR (Step 8), where it is
reviewed and annotated by the clinician (Step 9). Note that many providers
will require manual review of the data for clinical accuracy prior to committing
it to the EHR. This review requirement poses significant workload and process
implications to the future viability of RPM, discussed in more depth later.
The clinician enters modifications to the treatment plan and generates requests
for consultation (Step 10). Changes to the treatment plan are returned to the
RMMS (Step 11) and transmitted to the patient-local devices (Step 12). The
inbound data flows undergo similar decomposition and transformation as
outbound flows (Steps 5-7), remapping identity and terminology to local code
sets.
System designers should anticipate the need to support a large number of end
points with a high complexity and variability of transforms (e.g., HL7 v2.x,
HL7 v3, proprietary XML, proprietary delimited files) and translations (e.g.,
SNOMED CT, LOINC, RxNORM, ICD9/10) required across an array of
different transport protocols (e.g., SOAP over HTTPS, SFTP, MLLP, and
proprietary sockets). A powerful approach is the implementation of the HL7
v3 CDA [4] in the Integration Services environment (Step 5) as a normalized
view of RPM information, leveraging the full richness of the HL7 v3 Reference
Information Model (RIM). The CDA becomes in effect a Rosetta Stone,
making the subsequent translation to legacy, proprietary, and standardsbased systems predictable, reliable, and semantically correct. The incremental
adoption model inherent in CDA ensures the relative ease with which we
can populate optional segments with new information, such as Plan of Care,
while the SDOs work through the optimal encoding scheme. It also ensures
straightforward compliance with new CDA document types, such as the
Continua Health Alliance Personal Health Monitoring (PHM) Report [3], as a
minor transform from the baseline CDA.
“Note that many providers will
require manual review of the data for
clinical accuracy prior to committing
it to the EHR.”
The HL7 v3 RIM is an abstract healthcare
informatics model, generated by using Uniform
Modeling Language (UML) and consisting of
a set of classes, attributes, and relationships.
The HL7 CDA and other v3 specifications are
derived from the RIM and encoded by using
XML. The RIM is capable of representing Acts,
Entities, Relationships, Roles, and Participants,
and it is refined by using standard code sets and
controlled medical vocabulary.
Continua Health Alliance is a non-profit, open
industry coalition of more than 200 healthcare
and technology companies collaborating to
improve the quality of personal healthcare.
Continua is dedicated to establishing a system
of interoperable personal health solutions, with
the knowledge that extending those solutions
into the home fosters independence, empowers
individuals, and provides the opportunity for
personalized health and wellness.
Using HL7 to Encode Telehealth Data
“The standard is both precise and
adaptable, as demonstrated by the
Continua xHR Implementation
Guide.”
The HL7 v3 CDA Release 2 [4] is the ideal vehicle for healthcare data
integration. It is an informatics standard based on years of industry expertise, it
represents healthcare documents in their purest form, ranging from a progress
report, to a discharge summary, to capturing an MRI study as a standard
image set. The HL7 CDA can scale easily from early to advanced stages of
adoption: it can represent a container with basic summary information (such as
basic patient demographics, ordering physician, and a facsimile of a lab result
stored as an attachment), to a container with a longitudinal health record.
The standard is both precise and adaptable, as demonstrated by the Continua
xHR Implementation Guide [3], a variant of the CDA developed to define the
Personal Health Monitoring Report (PHMR) [10].
The real ingenuity of the CDA is the overlay of a series of templates or
constraints to the v3 RIM, to uniquely identify and encode sections of a
clinical document in a standard and semantically meaningful way. The HL7
v3 Continuity of Care Document (CCD) [9] was one of the first broadly
implemented set of constraints applied to the HL7 CDA Release 2 [4], and
it was selected by HITSP as the basis of their implementation guides. There
are now a whole complement of implementation guides based on either the
umbrella CDA or on the further constrained CCD, all of which aim to deliver
both human-readable and machine-consumable clinical information in a
systematized fashion.
Assigned Author
The HL7 CDA supports the concept of the Assigned Author being either a
human or a device, as depicted in Code Listing 1.
“The real ingenuity of the CDA is
the overlay of a series of templates or
constraints to the v3 RIM, to uniquely
identify and encode sections of a
clinical document in a standard and
semantically meaningful way.”

<author>
<assignedAuthor>
<assignedPerson>
…
</assignedPerson>
</assignedAuthor>
</author>

<author>
<assignedAuthor>
<assignedAuthoringDevice>
…
</assignedAuthoringDevice>
</assignedAuthor>
</author>
Code Listing 1: Machine-Computable XML: Assigned Author
In some cases, a summary report of RPM is generated along with clinical
notes, as part of a transfer of care or a request for consultation, and the use of
a human Assigned Author makes perfect sense. In other cases, information is
automatically collected by RPM devices, compiled into an HL7 CDA, and
forwarded to other healthcare systems for subsequent clinical analysis. In this
latter case, there is no human author who can be assigned, as the information
has yet to be reviewed by any clinical personnel. Similarly, while some regions
may require legal authentication of a clinical document, other regions may
delegate legal authentication to a device or system, and still others may opt to
release a clinical document prior to legal authentication. The HL7 PHMR does
an excellent job of both considering and supporting each of these variations in
usage models [10].
Medical Equipment
The HL7 PHMR [10] (based upon the work of the Continua Health Alliance
[3]) does a thorough job of specifying required peripheral manufacturer
information. Table 1 and Code Listing 2 show the Medical Equipment section
from the HL7 PHMR [10], depicting both the XML-rendered table and a
subset of the machine-computable section for a single device, respectively.
“The HL7 PHMR does an excellent
job of both considering and supporting
each of these variations in usage
models.”
Medical Equipment
System
Type
System
Model
System
System ID Production
Manufacturer
Spec
Blood
Pressure
Monitor
Pulse
Master
2000
Nonin
1F-3E46-789A-BCDE-F1
Regulated
Unspecified: Regulated
Serial
Number:
584216
Part Number:
69854
Hardware
Revision: 2.1
Software
Revision: 1.1
Protocol
Revision: 1.0
Prod Spec
GMDN:
Table 1: XML-rendered Table: Medical Equipment
Source: Health Level Seven, 2009 [10]
“Systems can transform the
terminology to other standard and
proprietary formats, precisely because
the standard is encoded in the first
place, just like the Rosetta Stone.”
<title>Medical Equipment</title>
…

<id root="1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"
assigningAuthorityName="EUI-64” extension="1F-3E-46-78-9A-BCDE-F1"/>
…

<playingDevice>
<code code="32033000" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT" displayName="Arterial pressure
monitor">

<translation code="MDC_DEV_SPEC_PROFILE_BPM”
codeSystem="2.16.840.1.113883.6.24" codeSystemName="MDC"
displayName="Blood Pressure Monitor"/>
</code>
<manufacturerModelName>…</manufacturerModelName>
</playingDevice>
Code Listing 2: Machine-computable XML: Medical Equipment
Source: Health Level Seven, 2009 [10]
“Semantic interoperability is the
highest form of data integration.”
Note the significance of the use of standard terminology in Code Listing 2,
which leverages both SNOMED CT and MDC code sets (refer to “code/code
system…translation code/code system”). This semantic encoding is what makes
the information machine-computable and enables interoperability. Systems can
transform the terminology to other standard and proprietary formats, precisely
because the standard is encoded in the first place, just like the Rosetta Stone.
Semantic interoperability is essential to enable clinical research and to facilitate
queries across a wide variety of data sources; however, semantic exchange is
only possible if the terminology has been first normalized to one of a few dozen
international healthcare terminology standards.
Levels of Interoperability
Semantic interoperability is the highest form of data integration, such that
receiving systems can readily and precisely consume information, encoded with
standard terminologies and code sets, with no loss of meaning or context for
abstract terms and concepts. This is the goal of the HL7 v3 RIM.
“Prior messaging standards tended to
stop short at syntax.”
Syntactic interoperability, the next lower form of data integration, exchanges
information by using agreed-upon syntax. A set of fields are specified along
with their syntax, but nothing is specified as to the possible range of values or
meaning. Prior messaging standards tended to stop short at syntax: they did
not address the crucial last step of semantics, and therefore left an incomplete
data standard wide open to conflicting interpretation and incompatible
implementations. For example, the earlier versions of HL7 v2.x messages
focused almost exclusively on syntax, and hence the expression “every v2.x
interface is a new v2.x interface.” Each implementation added proprietary
interpretations and extensions over time.
Integration at the lower five levels of the OSI model focus on standardizing
transport, protocol, and security, which is also the primary focus of such
groups as W3C, Continua, IHE, and IEEE. Technology standards are optimal
to address the exchange on the wire, while healthcare domain expertise is
optimal to address the syntax and semantics of the exchange.
Vital Signs
Table 2 shows a sample of the Vital Signs section of a PHMR, depicting the
XML-rendered table, while Code Listing 3 depicts a subset of the machinecomputable section for a single measurement. This example highlights the dual
role of the CDA construct: to provide highly accessible information viewable
by clinicians in a concise, easy-to-read format, along with a fully encoded,
machine-consumable version of the same information, capable of supporting
any degree of advanced analytics and clinical workflow. It is common in fact
for information in the machine-consumable section to be richer than that
depicted in the XML-rendered table. For example, the XML-rendered table
might present only summary or trend information, whereas it is perfectly
acceptable for the machine-consumable segment to include both raw and
summary information.
“It is common in fact for information
in the machine-consumable section
to be richer than that depicted in the
XML-rendered table.”
Vital Signs
Date Captured
Peripheral
Measurement
Value
Condition
Reference Range
2008-01-07 13:55:14.000
Blood Pressure
Systolic
137 mmHg
Alert
89-130
2008-01-07 13:55:14.000
Blood Pressure
Diastolic
85 mmHg
Normal
59-90
2008-01-07 13:55:14.000
Blood Pressure
Pulse
89 BpM
Normal
59-100
Table 2: XML-rendered Table: Vital Signs
<title>Vital Signs</title>
…

<code code="271649006"codeSystem="2.16.840.1.113883.6.96"
displayName="Systolic"/>
…

<value xsi:type="PQ" value="137" unit="mm[Hg]"/>

<interpretationCode code="A"
codeSystem="2.16.840.1.113883.5.83"/>
…

<participant typeCode="DEV">
<participantRole>
<id root="1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"
assigningAuthorityName="EUI-64" extension="1F-3E-46-78-9ABC-DE-F1”/>
</participantRole>
</participant>

<referenceRange>
<observationRange>
<value xsi:type="IVL_PQ">
<low value="89" unit="mm[Hg]"/>
<high value="130" unit="mm[Hg]"/>
</value>
</observationRange>
</referenceRange>
Code Listing 3: Machine-computable XML: Vital Signs
“Inclusion of this information
is crucial to be able to quickly
perform patient triage as well as
trending analysis and population
management.”
Note also the use of Observation/interpretationCode and Observation/
referenceRange in Code Listing 3, to indicate whether a particular reading
is considered within or outside of the reference range for that measurement
type. These data elements are optional, but are strongly encouraged as industry
best practice (i.e., “SHOULD”) by the HL7 PHMR [10]. Inclusion of this
information is crucial to be able to quickly perform patient triage as well as
trending analysis and population management.
Functional Status
Remote patient monitoring has a clear need for including questionnaire
assessments as a part of Functional Status. Assessments can range from
standard question-answer sets, recognized regionally as the authoritative
protocol for a given disease condition, to proprietary question-answer sets,
designed by particular institutions along with customized care plans. The
standard assessments are routinely used by payers and providers alike to gauge
individual patient functional status and assess overall population trending.
The HITSP Long Term Care–Assessments AHIC Gap/Extension [13] lists
several assessments applicable to the United States, including the Long-Term
Care Minimum Data Set (MDS), the Continuity Assessment Record and
Evaluation (CARE), the Outcome and Assessment Information Set (OASIS),
and the Inpatient Rehabilitation Facility-Patient Assessment Instrument
(IRF-PAI). There are widely recognized instruments worldwide for managing
chronic disease conditions such as diabetes, congestive heart failure, asthma,
or depression. Assessments can also be utilized as part of pre-qualification and
patient recruitment for clinical trials.
“There are widely recognized
instruments worldwide for managing
chronic disease conditions such as
diabetes, congestive heart failure,
asthma, or depression.”
AHIC and HITSP acknowledged the gap in the lack of specifications related
to assessments, and worked with HL7 to develop the CDA Framework
for Questionnaire Assessments DSTU [8]. Standardized information,
templates, guidelines, schedules, and scoring mechanisms are all needed to
fully comprehend assessments within the HL7 CDA. Currently, work is
divided amongst several different teams, including HITSP Consultation and
Transfer of Care; Quality; and Long Term Care Assessments: all are working
in conjunction with the HL7 Patient Care Work Group, the HL7 Structured
Documents Work Group, and a broad array of clinical and technology industry
experts.
Some assessment instruments have the concept of weighted points associated
with particular question responses, which can then be used to triage patients
who require immediate intervention. An extension of this is the concept of a
Scored Care Plan Report, with higher patient acuity associated with higher
points assigned to more significant health indicators. For example, Congestive
Heart Failure patients might score a 0 if they are coping well on a particular
day, versus a 5 or 6 if they suddenly put on additional weight or notice swelling
in their legs. The ability to encode this information by using standard CDA
templates, constraints, and appropriate terminology would be extremely
powerful to drive both analytics and clinical workflow.
“An extension of this is the concept of a
Scored Care Plan Report, with higher
patient acuity associated with higher
points assigned to more significant
health indicators.”
“The framework is very thorough and
nuanced in its handling of diverse use
cases.”
The great news is that both the CDA and specializations such as the HL7
PHMR permit the addition of optional sections such as Functional Status
to represent this type of information. However, for a system to accurately
consume and mediate the information, it would still require extensions to the
specification. The work to date from the CDA Framework for Questionnaire
Assessments DSTU [8] is outstanding in this regard, in making such rapid
progress in such a short period of time. The framework is very thorough and
nuanced in its handling of diverse use cases, both enabling early adoption
while parts of the specification are yet to be finalized, as well as demonstrated
capability to instrument very complex assessments, as evidenced by the
derivative work on the Minimum Data Set Version 3 (MDSV3) [8]. We urge
the SDOs to continue to aggressively pursue work in this area, essential to all
forms of RPM, long-term care, and other clinical settings.
In Table 3, we show an example of how we might render assessment responses
in human-readable form.
Functional Status
Session date/time: 2008-01-07 13:53:04.000
Assessment
Answer
Score
How are you feeling today compared to yesterday?
Worse
5
Have you taken all of your prescribed medication
over the past 24 hours?
Yes
0
Did you need to take any extra diuretic medication
in the past 24 hours?
Yes
10
Did you need to use any extra oxygen in the past
24 hours?
Yes, more
than normal
5
Total Score:
20
Table 3: XML-rendered Table: Functional Status
High priority should be placed on standardizing the templates to encode
patient assessments, including terminology, along with the concept of
assessment scales or scores where relevant.
“A Plan of Care is used to capture
‘What did we ask the patient to do?’
whereas the combination of daily
assessments and vital sign collection is
the answer to ‘What did the patient
actually do?’ ”
Plan of Care
Multiple SDOs and HITSP working groups are planning to address Plan
of Care as it relates to Consultations and Transfers of Care [5]. This is
another example of the power and flexibility of the CDA architecture.
While a traditional treatment plan might be best characterized by a set of
multidisciplinary protocols and a follow-up planned upon hospital discharge,
in RPM it takes on a different character altogether. Plan of Care includes
functional and other nursing assessments (not to be confused with physician
assessments of patient status, which are located in the CDA “Assessment and
Plan” section).
A Plan of Care is used to capture “What did we ask the patient to do?” whereas
the combination of daily assessments and vital sign collection is the answer to
“What did the patient actually do?” Thus, the combination of Plan of Care,
Functional Status, and Vital Signs can be used to gauge patient adherence
to the agreed-upon treatment plan, and can be used as a basis for long-term
outcomes analysis with respect to RPM. We would like to see the SDOs create
Plan of Care section constraints that cover both definition and scheduling
of standard assessments and vital signs collection. Such constraints would
be machine-consumable by different systems and encoded, by the use of
international terminology standards, to promote advanced analytics.
“We would like to see the SDOs create
Plan of Care section constraints that
cover both definition and scheduling
of standard assessments and vital signs
collection.”
Service Oriented Architecture (SOA) Principles
Remote patient monitoring truly represents a superset of healthcare integration
use cases, sitting at the hub of a complex coordination of care — across clinical
specialists, home care, lab, pharmacy, hospital, and assisted living facilities.
Chronic disease management adds a further layer of complexity, given that
most home-care and remote monitoring systems were developed as proprietary
systems with only a passing acquaintance with healthcare and technology
standards. Also, it is not uncommon for these CDM systems to be used
alongside one or more of the major commercial EMR systems.
SOA provides the essential grounding, agility, and extensibility to manage
and reduce complexity when integrating healthcare systems, services, and
information. It is adaptable to a challenging and ever-changing business
climate, and represents a proven return on investment [1, 2, 11, 12]. SOA
provides the necessary bridge between legacy and proprietary environments
and moves us towards standards-based deployments that can scale to handle
many network end points and a rich diversity of healthcare data services.
In this section we outline key considerations and SOA principles when
establishing an RPM solution.
Centralized
PYREX
Lab
550ml
400
300
200
Clinic
RX
Hospital
Federated
PYREX
Lab
550ml
400
300
200
Clinic
RX
Hospital
Flexible, Scalable Architecture to Support Any Deployment Model
With healthcare integration, it is important to leverage architecture that is
flexible across different deployment models and data-use agreements. Figure 3
depicts three common deployment models, wherein health information is
maintained in a centralized, federated, or hybrid database model. The model
selected largely depends upon data-use agreements in the region — whether to
maintain data centrally to a given region, remotely (federated), or as a hybrid
model of the two. The centralized model is optimum both in terms of
performance and access to a consistent, normalized data set, suitable for both
healthcare delivery and clinical research. However, the centralized model
requires the political will by all participants, public and private alike, to agree
to centralized data sharing and data-use agreements.
Hybrid
PYREX
Lab
550ml
400
300
200
Clinic
RX
Hospital
Figure 3: Data Origin Flexibility
“Due to concerns over performance
and availability, deployment models
frequently shift over time from
federated to hybrid.”
Due to concerns over data sharing, ownership, and local control, the federated
model is frequently chosen over the centralized or hybrid. When a discharge
summary or lab report is required, a record locator service query is issued from
the center to each of the federated or member organizations. If the federated
service is available and the appropriate agreements are in place, one or more
relevant documents are returned that pertain to the patient in question. Due to
concerns over performance and availability, deployment models frequently shift
over time from federated to hybrid, maintaining a small set of demographic
data and centralized pointers to records maintained at the perimeter.
The federated model can be quite effective for very large, distributed data sets,
but the records must be normalized at the edge by the use of agreed-upon
terminology standards. The political will to use such standards can be even
more challenging to achieve than that required for the centralized model. An
excellent example of the federated model is the caBIG (Cancer Biomedical
Informatics GRID at cabig.nci.nih.gov), which links physicians, patients, and
researchers to clinical, cancer, and genomics repositories distributed worldwide
in a standard normalized fashion.
RPM is to leverage a flexible
architecture which can scale from
small institutions, to regional health
information exchanges, to national
networks.”
Remote patient monitoring requires the integration of health information from
a variety of disparate sources. SOA is well suited to adapt and extend to this
level of service, data origin, and terminology complexity. A key success factor in
deploying RPM is to leverage a flexible architecture which can scale from small
institutions, to regional health information exchanges, to national networks.
Finally, the deployment model and technology selected must readily scale to
processing at the core or at the edge of the network.
Service Extensibility, Virtualization of End Points
Traditional peer-to-peer approaches to integration lead to the N2 problem as
depicted in Figure 4, in that each and every application requiring integration
causes a geometric expansion of up-front cost and ongoing maintenance. In
healthcare integration, the N2 problem is made manifest by the inconsistent
adoption of healthcare and technology standards by legacy and proprietary
systems. When a new application joins the network, each and every adapter has
to be modified, in addition to the new application.
n=2
n=3
“In healthcare integration, the N2
n=6
problem is made manifest by the
inconsistent adoption of healthcare
and technology standards by legacy
Figure 4: N2 Problem in Healthcare
and proprietary systems.”
Custom Interfaces
“A key success factor in deploying
100
90
80
70
60
50
40
30
20
10
0
1 2 3 4 5 6 7 8 9 10
HIT Systems
Integration Brokers change the cost model from geometric to linear, but have
their own share of challenges, with the risk of establishing heterogeneous
“islands” of integration. Integration Brokers rely upon a hub-and-spoke
architecture, creating a single point of failure by routing all messaging traffic
through a central hub. Only with a standardized information model, service
extensibility, and virtualization of end points, provided by an Enterprise
Service Bus (ESB), can one completely address the N2 problem.
The heart of the N2 problem lies in the simplistic framing of integration as a
two-dimensional use case. When we frame the exchange of health information
as a simple, bidirectional exchange between a total of two points, we obfuscate
the actual complexity involved. In reality, the RPM exchange requires multiple
data sources, or network end points, in order to complete the CDM view of
the patient, including vital signs, assessment responses, functional status, lab
results, prescriptions, diet, exercise, treatment plan, and clinical notes, to name
just a few. The information needs to be addressable by using a standardized
information model, and over time, each of the data services should be exposed
by using a standard set of query and retrieval methods.
“The heart of the N2 problem lies in
the simplistic framing of integration as
a two-dimensional use case.”
A service network architecture allows for building the “on-ramp” once, with no
adapter maintenance required, as other applications join or leave the network.
Service extensibility serves to virtualize the end points, abstracting the details of
transport protocols and peer-to-peer connections. Services can be dynamically
registered, discovered, and rerouted to scale as performance and reliability
needs dictate.
Network Compute Model
The HL7 v3 CDA Release 2 [4] constrains the v3 RIM and leverages the full
richness of its healthcare informatics model and standardized terminology,
delivering computable, healthcare information as well as human-readable
clinical documents. By first composing all of the telehealth data to the HL7 v3
CDA Release 2 (i.e., the network on-ramp in Figure 5), it becomes a repeatable
exercise then to perform any secondary transforms to legacy or proprietary
messaging protocols and local terminology (i.e., the network off-ramp).
Healthcare Service Network
Network
On-Ramp
“Services can be dynamically
registered, discovered, and rerouted to
scale as performance and reliability
needs dictate.”
Healthcare
Service using
HL7 CDA
Canonical
Transform
Canonical
Figure 5: Service Network Architecture
This integration pattern accelerates adoption of the latest healthcare informatics
standards, while lowering the barriers of adoption for smaller organizations that
need to proceed at their own pace.
A robust network informatics exchange model can be used to establish trust
at the network level — a healthcare dial tone. Peer systems may validate,
authenticate, and audit the encrypted XML payloads at any point in the
network. Moreover, the network compute model enables the ability to route,
compose, and decompose fine-grained business objects according to national
and regional, legal and regulatory, privacy, data protection, and patient consent
requirements.
Pluggable Services in the Cloud
“Since the service location is
virtualized, and the service
implementation is encapsulated,
a service can be readily created or
replaced without impacting existing
service consumers.”
SOA provides the ability to leverage services available within the data center or
across the Internet. New services can be brought online and directly utilized by
network participants, without requiring additional modifications to each end
point. Since the service location is virtualized, and the service implementation
is encapsulated, a service can be readily created or replaced without impacting
existing service consumers. The OMG/HL7 Healthcare Services Specification
Project (HSSP at http://hssp.wikispaces.com/) is working to define standard
Web service methods to access critical healthcare infrastructure services,
including entity identity, controlled terminology, record locator, decision
support, and clinical research filtered query services. Similarly, there is a need
for advanced healthcare data services, such as drug interaction checks, adverse
event reporting, clinical trial recruitment, and public health reporting. SOA
design methodology allows for incremental implementation, at first utilizing
simple data match routines and then, when the complexity of exchange
dictates, readily switching to industry-strength identity and terminology
services, all without changing the service interface.
Deployment Considerations
“What is required, however, is deep
healthcare domain expertise, a keen
sense of customer requirements, and an
understanding of the context in which
the system will be used.”
Effective RPM deployment requires the application of industry best practices
with respect to information technology, data center operations, enterprise
service delivery, and robust security and privacy measures. The technical
challenges in healthcare are not insurmountable; rather, they can be solved by
using well-known solutions and design patterns. What is required, however, is
deep healthcare domain expertise, a keen sense of customer requirements, and
an understanding of the context in which the system will be used. In order to
fully realize the potential of RPM, we must arrive at the right combination of
technology and process.
Patient Acuity and Mode of Healthcare Delivery
Patient acuity and the concomitant mode of healthcare delivery are arguably
the most important determinants of RPM requirements. Patient acuity
determines the level of monitoring and likelihood that intervention will be
required, the frequency of data collection, the criticality of reference ranges
and alerting mechanisms, and the relative intolerance for data latency. The
mode of healthcare delivery — whether it be a wellness coach, a visiting nurse,
community outreach, an assisted living facility, hospital discharge monitoring
to avoid readmission, population management, or patient-empowered
healthcare — tends to be matched to patient acuity and provider service level
agreements. Contact with the patient, and the relative need to process the
clinical findings, will therefore range from occasional, monthly, quarterly,
daily, hourly, or perhaps even more frequent when a sudden decline in health
is detected. The duration of RPM deployments could be measured in weeks
in the case of hospital discharge monitoring, months in the case of high-risk
pregnancies, or years when monitoring elderly patients with co-morbidities.
“The mode of healthcare delivery tends
to be matched to patient acuity and
provider service level agreements.”
Data Latency and Modes of Transmission
As discussed earlier, tolerance for data latency is largely determined by patient
acuity of the target population. Relatively healthy patients, coupled with
wellness coaches, can tolerate high data latency with summary reports over
periods as much as a few months at a time. High-acuity patients require
more frequent monitoring, with data latency approaching near real-time.
High data latency can readily be accommodated by scheduled, file-oriented,
and store-and-forward processes to perform data integration. In contrast,
low data latency requires end-to-end integration performed via Web services
every few minutes, where the incremental transmission is closer to a single
patient session, containing the latest raw measurements and assessment
responses, rather than a complete trend analysis of the past period. Alerts and
notifications can be generated via real-time, event-driven triggers, whereas
batch operations and monthly summary reports can be scheduled to occur
during off-hour processing.
“Alerts and notifications can be
generated via real-time, event-driven
triggers, whereas batch operations
and monthly summary reports can
be scheduled to occur during off-hour
processing.”
Volume and Quality of Data
RPM involves significantly more data than what is typically anticipated for
an EHR, such as a clinical encounter. Patients may be instructed to take vital
sign measurements multiple times per day in addition to responding to various
assessment questions. One of the chief areas of ongoing investigation is the
optimal level of summarization of the PHMR. Different clinicians will likely
want a full range of options, from daily, monthly, or quarterly to a filtered
summary, depending upon patient acuity and the mode of healthcare delivery.
“Different clinicians will likely want
a full range of options, from daily,
monthly, or quarterly to a filtered
summary, depending upon patient
acuity and the mode of healthcare
delivery.”
Once the report design is optimized, additional adaptations may be necessary
to the recipient system in order to fully leverage the additional rich data types,
process alerts, and triage patients based on clinical findings. In particular, it
is unlikely that recipient systems are prepared to work with patient-specific
reference ranges, threshold violations, assessment questionnaires, or weighted
scores for industry standard protocols. Some systems are unprepared to process
datetime stamps on individual measurements, because of the prior exclusive
focus on clinical encounters in office settings. In other words, while a given
office medical system might record the date of the office visit, it rarely records
the time of an individual measurement. While the concept of an RPM “patient
session” can be likened to an office visit, the recipient medical system is
unprepared to process the sheer volume of RPM sessions and measurements.
“All points along the end-to-end data
flow should be instrumented and
monitored for effective operation and
patient safety.”
“We have identified the need to define
tiers of thresholds to separately drive
patient and clinician workflows and
modes of intervention.”
As clinical systems and processes evolve to process data from RPM, the need for
more sophisticated methods of patient triage, alert, and notification will also be
required. For example, a large number of normal readings from a moderatelysized patient population will quickly outpace the most efficient of care-manager
organizations, if workflows require the manual acknowledgement of all
readings, rather than triage based on out-of-range measurements. Conversely,
if an organization becomes overly dependent upon the direct integration of
RPM data without also developing adequate means for systems monitoring,
an undetected outage or transmission failure might inadvertently create a
false impression that patient readings are within normal limits. It is critical,
therefore, to develop adequate systems monitoring and failsafe methods.
For example, reports should be appropriately annotated with synchronized
datetime stamps, indicating both the time of report generation and the time of
the last data transmission. All points along the end-to-end data flow should be
instrumented and monitored for effective operation and patient safety.
Threshold violations, especially life-threatening ones, need to trigger specific
workflows that are customizable by practice, by co-morbidities, by target
populations, and by individual patients. We have identified the need to define
tiers of thresholds to separately drive patient and clinician workflows and
modes of intervention, ranging from patient education, to clinician referral,
to emergency hospital admission. There is also the need to capture both the
trigger event and the clinical intervention as part of analytics. For example, a
patient’s oxygen saturation falls dangerously low, which triggers an alert and
results in some form of patient intervention — whether a phone call, an SMS
text message, a video conference with a clinician, or a house call from a visiting
nurse. The clinical intervention may result in a change in protocol, a lab order,
a medication change, or hospitalization. Each of these events needs to be
associated with a standard measure of outcomes in order to support analytics
for evidence-based medicine and drive further improvements to healthcare.
Clinician Workflow and Reimbursement Model
Another important consideration in the integration of RPM information is
clinician workflow and the reimbursement model. Some jurisdictions require
that a clinician manually review and accept each and every measurement prior
to importing the data into the institutional EHR. This follows standard clinical
practice of signing off when reviewing external lab results, yet again, the
volume of data is fundamentally different when considering RPM.
“Annotating the data stream with the
source and method of reporting helps
to account for these differences in
policies.”
Some institutions extend the system boundary of the EHR to encompass any
automated data capture but draw the line at information that is patient-reported
or otherwise manually entered, such as a PHR containing diet and exercise
journal entries. Data that are grandfathered in as automatic data capture might
not require the manual approval step, whereas patient-reported data may
be reviewed but perhaps not incorporated into the institution’s legal record.
Annotating the data stream with the source and method of reporting helps to
account for these differences in policies.
Accommodations are required for both the level of summary and raw
information in a given report. Streamlined mechanisms are required to process
messages through the clinical inbox, along with careful consideration as to what
level of clinical staff might be able to process what level of data on behalf of the
doctor, in order to potentially offload this manual step.
Further, the clinical reimbursement model is frequently called into question
with respect to RPM. Some reimbursement models attempt to equate RPM
with an office visit, while others only reimburse when the patient establishes
and maintains good tolerance of pre-established thresholds. Each of these
considerations will have an impact on the rate of adoption of RPM, especially
when combined with additional processing overhead on the part of the
physicians to periodically review the results.
“Some reimbursement models attempt
to equate RPM with an office visit,
while others only reimburse when the
patient establishes and maintains good
tolerance of pre-established thresholds.”
Trans-border Data Flow Considerations
Careful attention to detail will be required for any deployment in which
integration is planned across borders of state/provinces, regional, or national
boundaries. Privacy and data protection laws are rapidly changing worldwide,
with significant penalties for mishandling of data and breach of privacy.
Advanced workflow, transformation, and routing engines will be required
to comply with local data protection regulations and policies. Special
consideration is due when determining where to locate a primary or alternative
data center hosting patient data, since a number of countries require that
protected health information (PHI) not cross national boundaries. To manage
and track patient consent and negotiate appropriate data use, business associate
and data controller/supplier agreements are all essential, regardless of whether
or not information crosses any recognized governmental boundaries.
“Privacy and data protection laws are
rapidly changing worldwide, with
significant penalties for mishandling
of data and breach of privacy.”
Identifying Systems of Record
“While clinical data might be easily
segregated between different systems
of record, it is highly likely that every
system maintains its own copy of
demographic data.”
Identifying a single system of record (i.e., a single authoritative source for
each and every data element) is essential to any successful integration project
and frequently overlooked in applications such as RPM. It is typical for even
small organizations to already have multiple systems in place for purposes of
chronic disease management, population management, a primary EHR data
repository, a separate system for lab results, etc. The addition of telehealth data
likely represents the addition of one or more systems to an already complex and
disorderly mix.
A key area of concern is patient and clinician demographics. While clinical data
might be easily segregated between different systems of record, it is highly likely
that every system maintains its own copy of demographic data. Considerations
must be given both from a systems and a workflow perspective to demographics
synchronization, import, and ongoing maintenance. The older systems likely
do not have a method to disable manual edits to demographics, yet one must
ensure that clinicians are always working from an authoritative source of
patient and clinician demographics and contact information.
“Provisions are made to disable
manual edits in the recipient systems,
or at least ensure that processing
detects, logs as an exception, and
overrides any unauthorized changes.”
“Common identity mismatch errors
tend to require a small staff to resolve
In an advanced integration deployment, the demographics system of record
updates the recipient systems with the latest information, including translation
of identity to the recipient system, via an entity identity service (EIS).
Provisions are made to disable manual edits in the recipient systems, or at
least ensure that processing detects, logs as an exception, and overrides any
unauthorized changes.
In mixed environments with both legacy and newer systems, a complex
scheme of automated demographics integration along with a carefully designed
business process is required. A central system can be configured to synchronize
demographics to each of the recipient systems. When manual edits in each
system cannot be disabled, they must be controlled via business process,
training, and careful oversight to ensure that changes in demographics are only
entered into the central system. Common identity mismatch errors tend to
require a small staff to resolve and maintain on an ongoing basis.
As healthcare systems integration becomes more complex, encompassing
multiple end points and service providers, each with their own independent
systems of record, it becomes paramount to employ an industry-strength EIS to
accurately address the identity match problem. Industry leaders in EIS leverage
advanced stochastic algorithms for matching against multiple demographics
attributes to disambiguate identity. The OMG/HL7 Healthcare Specifications
Services Project (HSSP) is working to define standard Web service interfaces for
common capabilities like EIS, such that different commercial services may be
deployed without requiring a change to the implemented interface.
and maintain on an ongoing basis.”
Customization Requirements
There are a number of deployment considerations when establishing a remote
patient-monitoring solution. The AHIC use cases are foundational to defining
routine healthcare interactions and processes, required data elements, and
terminology constraints to standardize the exchange. It is also important to
distinguish the areas of local variation and future development, such as those
identified in the RPM sequence and interaction diagrams (Figures 1 and 2,
respectively). It is important to control the level of customization required
for any given solution to something that delivers real value to the customer,
both in the short-term and in the reasonable future, yet is practical enough to
represent low maintenance over time. While anything is technically feasible, it
is not practical for a business to develop a system to be all things to all people.
It is critical to establish up front some of the key business drivers, including
patient acuity, target mode of healthcare delivery, and the relative tolerance for
data latency. From this baseline, customization mechanisms can be established
to allow for local variation, leveraging codeless configuration changes to
metadata, rather than requiring a code recompile and system overhaul for each
deployment.
“While anything is technically feasible,
it is not practical for a business to
develop a system to be all things to all
people.”
Conclusion
Remote patient monitoring represents a critical intersection of healthcare
information integration, embodying the need for healthcare informatics
standards, careful consideration of workflow and system deployment tradeoffs,
and direct engagement with the patients and clinicians who work with the
system. The use of HL7 CDA helps to accelerate adoption of healthcare
standards by properly constraining the rich schema and vocabulary of the
RIM, and lowering the barriers of entry through incremental evolution. The
use of SOA design principles enables us to respond to changes in business
drivers and adapt to the complexity of healthcare integration end points.
Terminology standards drive computable information which in turn enables
advanced analytics, clinical research, and transformational healthcare delivery.
We are actively working with the SDOs in pursuit of future enhancements to
the existing healthcare informatics standards.
References
[1]
Bass, Christy and Lee, J. Michael. 2002. “Building a Business Case for
EAI.” eAI Journal, January 2002, pp. 18-20.
[2]
Booz Allen Hamilton. 2005. “Canada Health Infoway. Pan-Canadian
Electronic Health Record: Projected Costs and Benefits.” March 2005.
At www.infoway-inforoute.ca.
[3]
Continua Health Alliance. 2009. “Continua Design Guidelines.” V1.0,
June 2009. At www.continuaalliance.org.
[4]
Dolin R.H., Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV,
Shabo A, (Editors). 2005. “HL7 Clinical Document Architecture,
Release 2.0. ANSI-approved HL7 Standard.” May 2005. Ann Arbor,
Michigan: Health Level Seven, Inc. At www.hl7.org.
[5]
Healthcare Information Technology Standards Panel (HITSP). 2008.
“Consultations and Transfers of Care Interoperability Specification.”
HITSP/IS09. Released for Implementation. 20081218 V1.0.
At www.hitsp.org.
[6]
“Remote Monitoring Interoperability Specification.” HITSP/IS77.
Released for Implementation. 20081218 V1.0. At www.hitsp.org.
[7]
“Remote Monitoring Observation Document Component.” HITSP/
C74. Released for Implementation. 20090708 V1.1. At www.hitsp.org.
[8]
Health Level Seven (HL7). 2009. “Implementation Guide for CDA
Release 2: CDA Framework for Questionnaire Assessments (Universal
Realm) Draft Standard for Trial Use (DSTU) Release 1.0.” April 2009.
At www.hl7.org.
[9]
Health Level Seven (HL7). 2007. “Implementation Guide: CDA
Release 2 – Continuity of Care Document (CCD).” April 01, 2007.
At www.hl7.org.
[10] Health Level Seven (HL7). 2009. “Implementation Guide for CDA
Release 2.0 Personal Health Monitoring Report (PHMR) Draft
Standard for Trial Use (DSTU) Release 1.” At www.hl7.org.
[11] OMG SOA Consortium, CIO Magazine. 2008. “OMG SOA
Consortium and CIO Magazine Announce Winners of SOA Case Study
Competition.” At www.soa-consortium.org.
[12] Schindler, Esther. 2008. CIO Magazine. “Service-Oriented Architecture
Pays Off for Synovus Financial.” September 30, 2008. At www.cio.com.
[13] U.S. Dept. of Health and Human Services (HHS), Office of the
National Coordinator for Health Information Technology (ONC).
2008. “Long Term Care–Assessments. AHIC Extension/Gap.”
December 31, 2008. At www.hitsp.org.
Acknowledgements
Special thanks to Dr. Robert H. Dolin, co-chair of the HL7 Structured
Documents Committee, who assisted us in developing our initial CDA
models.
Author Biography
Kristina M. Kermanshahche is Chief Architect for Intel’s Digital Health
Group. Her research interests include SOA as applied to regional and
national healthcare architectures, CDM from home health to clinical trials,
and translational biomedical informatics. She was the Lead Architect for the
Intel SOA Expressway and contributed to the Intel Mobile Clinical Assistant
and the Intel Health Guide; she has a patent pending in healthcare semantic
interoperability. Her twenty-five year career in software development
spans nearly every industry, with an emphasis on complex distributed
systems, multithreading, high availability, networking, and database design.
She received her B.A. degree in 1988 from the University of Oregon in
Political Science and International Studies, magna cum laude. Her e-mail is
Kristina.M.Kermanshahche at intel.com
Copyright
countries.
Personal Health Device Interoperability
Contributors
Douglas P. Bogia
Intel Corporation
Rick Cnossen
Continua Health Alliance
Chris Gough
Intel Corporation
Abstract
Healthcare costs continue to spiral upwards to the point of prompting
national mandates for change in the whole healthcare system. Technology has
advanced to a point where personal telehealth systems provide viable, costeffective solutions and represent a very real opportunity to help control costs.
In order for deployment to become widespread, an ecosystem of standardsbased interoperable components (starting with the consumer-facing device) is
essential. In this article, we discuss the challenges related to creating such an
ecosystem and examine the efforts of the Continua Health Alliance to address
this need.
Introduction
Several factors have converged to provide new opportunities to address user
needs in the healthcare domain:
Index Words
Continua Health Alliance
Healthcare
Interoperability
Standardization
Communication
Cost Reduction
•• The dramatic rise in costs associated with established healthcare services.
•• A global increase in the number of older adults who are most likely to
require these services.
Technological advances, such as innovations in networking technologies and
a rapid increase in the number of Internet-connected devices, enable the
development of solutions that address user needs in a cost-effective manner.
These technologies also allow people to remain safely in their own homes for a
longer period of time. Personal telehealth systems composed of an ecosystem
of standards-based interoperable components are the building blocks of these
solutions. In this context, we define personal as systems that are used in a home,
and we define telehealth as the way in which communication technologies, such
as a phone line or broadband Internet access, are used in healthcare services.
In this article, we describe in more detail the underlying need for
interoperability between these components, the approach that was used by the
Continua Health Alliance [1] to define and design such a system, and some of
the key challenges that were encountered along the way.
“Personal telehealth systems composed
of an ecosystem of standards-based
interoperable components are the
building blocks of these solutions.”
104 | Personal Health Device Interoperability
Need for Device Interoperability
While there are many challenges associated with the successful design,
implementation, and deployment of personal telehealth systems, one of the
more obvious problems present in early telehealth solutions was a lack of device
interoperability or well-defined standards to which technology companies
could develop their products. In the next sections we discuss these issues in
more detail from both the integrator and purchaser perspective as well from the
product designer perspective.
Integrator and Purchaser
Telehealth stakeholders, both system integrators (companies producing
telehealth solutions made up of components from a number of different
vendors) and system purchasers (healthcare providers that purchase these
solutions and offer them to their patients or members) require a wide variety
of system vendors and components to select from. These stakeholders produce
or consume, respectively, a large number of telehealth systems and need to
protect themselves from undesirable situations, such as a component vendor
going out of business or being unable to deliver the desired volume of system
components in a given timeframe. Furthermore, the presence of many
component vendors competing for business drives down costs, improves the
quality of solutions, and encourages adding differentiating features to these
solutions.
“The presence of many component
vendors competing for business drives
down costs, improves the quality of
solutions, and encourages adding
differentiating features to these
solutions.”
However, the ability for integrators or purchasers to select from a wide variety
of personal health devices offered by multiple vendors is only possible if the
devices are compatible with one another. This compatibility is enabled by welldefined communication interfaces between the various system components.
Product Designer
From the perspective of a product designer, device interoperability is also an
essential need. For instance, without interoperable standards, a system designed
to communicate with a wide range of telehealth peripherals (for example,
weight scales, blood pressure monitors, glucose meters) must implement
proprietary data modeling and communication protocols over a variety of
transport technologies , such as serial, Bluetooth*, and infrared.
“Without interoperable standards, a
Product designers need to create a device-specific software adapter such that
their system can communicate with each of the peripherals. This leads to
inefficiencies in terms of both software development and system validation.
Likewise, designers of peripherals must design data and communication
protocols. Since these are specific to their device, the implementation of device
driver(s) for target operating system(s), user applications with GUIs, and
documentation is necessary.
modeling and communication
system designed to communicate with
a wide range of telehealth peripherals
must implement proprietary data
protocols over a variety of transport
technologies.”
Personal Health Device Interoperability | 105
“The necessary, interoperable solution
minimizes cost, improves design and
development efficiencies, and enables
separation of concerns for each of the
parties involved.”
The necessary, interoperable solution minimizes cost, improves design and
development efficiencies, and enables separation of concerns for each of the
parties involved. Consequently, device vendors can focus on devices, software
vendors can focus on software development, and service providers can focus
on service delivery, without requiring each party to have intimate knowledge
of every component that makes up the overall solution. Such an interoperable
solution can be achieved by defining communication interfaces in an
unambiguous set of standards and guidelines.
Challenges to Standardization
There are many challenges and barriers to standardization of device interfaces
in the personal health domain. In this section we explore some of the more
difficult ones.
Confluence of Domains
“It is imperative to converge on a
single unified solution yet difficult to
define a single solution that is both
efficient and optimum for all options
in the spectrum.”
“The challenge is in creating a generic
framing protocol that can be applied
to all application areas in order to
normalize collected data.”
The scope of the personal health domain is quite large and ranges from
regulated clinical disease management devices to unregulated consumer-grade
fitness devices. From an architectural and practical standpoint it is imperative
to converge on a single unified solution yet difficult to define a single solution
that is both efficient and optimum for all options in the spectrum.
Regulated Environment Versus Consumer Environment
Devices that are intended for a regulated environment (for example, US
FDA Class 2 Glucose Meters for a medical professional to treat diabetes) and
consumer grade devices (for example, a personal pedometer to track activity
levels) are starkly different. These differences show up in the requirements
(security levels, privacy restrictions, data reliability, and logging) as well as in
the level of testing required (stress testing, off-nominal conditions, etc.). These
differences make the decision-making process for interoperability standards
difficult as there are always tradeoffs.
Diversity of Applications
The current state of the personal health market is such that there are
independent vertical application solutions (for example, health and fitness,
disease management, and aging independently). The broad vision for an
interoperable solution is to eliminate these divisions in order to allow for
innovative solutions that span domains and create optimum value for the
consumer. For example, many consumers of disease-management applications
could benefit from an integrated application that accepts fitness data in order
to evaluate the effectiveness of a particular exercise against a particular disease.
The challenge is in creating a generic framing protocol that can be applied to
all application areas in order to normalize collected data. This can be difficult
as different domain applications have different approaches for some of the
common elements. For example, the timestamp granularity for diseasemanagement applications tends to be higher than for aging-independently
applications.
The Nascent Personal Health Industry
The personal health industry is relatively young and lacks mature standardsbased solutions for interoperability. This necessitates developing new standards
or profiles in many cases instead of using existing standards that have been used
and validated over time. It takes a notoriously long time for the standards to
be created, accepted by the industry, augmented with tools, and understood by
engineers. Such a lengthy process runs counter to the desire to quickly define
solutions for industry build-out.
“It takes a notoriously long time for
the standards to be created, accepted
by the industry, augmented with tools,
and understood by engineers.”
International Need
With the ubiquity of the Internet, common communication advances, multinational companies, and global markets there is an opportunity and a strong
desire to create solutions that can be deployed internationally. International
deployment can capitalize on a company’s initial development investment
and increase overall revenue by expanding market opportunities. Within
the international standards organization, these solutions require geographic
differences among standardization processes to be harmonized. Harmonization
complicates and slows down the standardization process. For example, UScentric solutions tend to use US Standard Development Organizations (SDOs)
such as IEEE, ANSI, and W3C, while EU-centric solutions tend to use EU
SDOs, such as CEN, ETSI, and CENLEC. There are some fundamental
differences in approaches also. For example, the United States approach tends
to be industry-driven, while the European Union approach tends to be more
government-driven. These differing approaches impact the process and must
be reconciled. Additionally, there are regional and demographic differences
that must be overcome. For example, demographics data (address, gender) vary
among countries, and a common structure must be defined to allow for all
system instantiations.
“The United States approach tends
to be industry-driven, while the
European Union approach tends to
be more government-driven.”
Business Motivation
Despite the best intentions, there are many existing standards that are
incomplete or unused. The bottom line for many companies is that investing in
the development and implementation of standards must benefit them to some
degree economically. For new, nascent markets, such a return on investment
can be difficult to project and demonstrate which, in turn, can lead to a dearth
of volunteers or to slow uptake in product build-out.
The Continua Health Alliance Solution
This section introduces the Continua Health Alliance and describes how it
addressed the challenges and issues described in the preceding sections.
“For new, nascent markets, such a
return on investment can be difficult
to project and demonstrate which,
in turn, can lead to a dearth of
volunteers or to slow uptake in product
build-out.”
Approach
The Continua Health Alliance is an open industry coalition of over 200
healthcare and technology companies focused on interoperability in the
personal healthcare domain. Founded in 2006, the Continua Health Alliance
addresses the unique combination of challenges just discussed. The Continua
Health Alliance leveraged examples from other solution domains such as home
networking (for example, Wi-Fi Alliance and Digital Living Network Alliance)
in order to help define its overall approach. The Continua Health Alliance
adopted the following methodology:
•• Select an existing, applicable set of industry standards.
•• Extend these selected standards where required to meet user needs identified
in use-cases and requirements.
•• Eliminate ambiguity in interpretation of these standards through a
collection of interoperability guidelines.
In the following sections we describe the process, architecture, and final
implementation that address the challenge of enabling an ecosystem of
interoperable, standards-based personal-healthcare devices.
Process
The Continua Health Alliance process begins with use-case collection and
refinement. After agreeing upon the use-cases, requirements are elaborated
upon and architecture is defined. Existing standards are then reviewed to
determine if a standard already exists that meets most, if not all, of the
requirements. If so, it is selected. If not, a new one is created. Next, the
Continua Health Alliance creates interoperability guidelines to define profiles
over the standards to serve as a basis for product certification. To assist
companies that make products adhering to the guidelines, the Continua
Health Alliance hosts interoperability plugfest events to ensure products from
multiple vendors work together. The Continua Health Alliance also establishes
a certification and testing program that ensures product compliance with the
guidelines. It certifies that products pass the certification and testing program,
and if they do, the products may use the Continua Health Alliance logo.
Use-Case Collection
With more than 200 companies in the Continua Health Alliance, converging
on a set of priority use-cases for each iteration can be a challenge.
To deal with this challenge, the Continua Health Alliance maintains a rigorous
process that includes the following steps:
•• Crisply define candidate use-cases by using a template that includes title,
date, version, description, scope, actors, preconditions, flow, and technical
feasibility.
•• Consolidate and generalize use-cases, segmenting work along market
boundaries in order to encourage participation in areas of expertise and
business interest. This eliminates redundancy and brings like-minded
companies together to truly describe a consolidated industry need.
•• Review use-cases to carefully constrain scope (for example, consider product
instantiations, resourcing, schedule) and appropriate focus (for example,
ensuring component interfaces are defined but do not overly address
product capabilities as the interfaces are opportunities for differentiation).
•• Include a review cycle with domain experts and consumers to ensure usecases represent real and useful solutions.
Requirements Elaboration
Once the use-cases are complete, they are decomposed into system
requirements. This process entails analyzing the use-case to pull out
actors, actions, and assumptions and converting these into corresponding
requirements.
Standard Selection and Development
Once the requirements are defined, members of the Continua Health Alliance
search for existing SDOs and standards that best satisfy the requirements and
desired characteristics. In cases where there is no standard, the members must
select an SDO for hosting a new standard and apply resources to create the
new standard. The following questions are considered to evaluate the selected
standard:
“In cases where there is no standard,
the members must select an SDO for
hosting a new standard and apply
resources to create the new standard.”
•• Does the standard adequately address the requirements from the selected
use cases?
•• Does the SDO create international standards or a path to generate them?
•• Is the SDO open for participation from member companies?
•• If a standard exists, how well is it harmonized with related domain
standards? If standards do not exist, how open is the SDO to harmonizing
with other standard organizations?
•• How is the standard accessed and what are the control mechanisms for the
standard from the SDO?
•• What are the intellectual-property (IP) rights for standards from the SDO?
•• What are the costs pertaining to licensing, implementation, and access?
•• Does the SDO provide tool support for creating or testing implementations
of their standards?
•• What is the level of adoption and maturity of standards from the SDO?
Guidelines Development
Once the standards are available, Continua Health Alliance members compare
the standard against the identified system requirements to identify remaining
gaps. The Continua Health Alliance creates interoperability guidelines to
address these gaps, expand on the standards, minimize optionality, and
facilitate tight interoperability.
“The Continua Health Alliance creates
interoperability guidelines to address
these gaps, expand on the standards,
minimize optionality, and facilitate
tight interoperability.”
“The lab uses an automated test
tool, a system simulator, and mature
certified reference devices to verify
interoperability.”
Test Plans and Tools
After standards and the interoperability guidelines are completed, the Continua
Health Alliance creates test assertions and procedures. The test procedures
verify that a product adheres to the appropriate standards and guidelines.
All procedures can be run manually; however, as many as possible are also
automated to reduce the level of product certification effort.
Certification Lab
When a product is completed, it is tested in a certification lab. The device
is run through various procedures to receive certification. The lab uses an
automated test tool, a system simulator, and mature certified reference devices
to verify interoperability. Once testing in the lab produces a satisfactory result,
a certification can be issued and the product can use the Continua Health
Alliance logo for marketing purposes.
Architecture
“The architecture defines the subsystems
that make up the overall system and
describes how they interact.”
One of the key activities that goes hand-in-hand with the collection of
requirements discussed in the preceding Requirements Elaboration section
is the definition of the system architecture. The architecture defines the
subsystems that make up the overall system and describes how they interact.
Just as important, it provides a useful model for organizing the requirements
and offers guidance to engineers who look for applicable standards and
technologies during the subsequent implementation phase.
Early on in the process of designing the Continua Health Alliance Device
Architecture, there were two critical challenges that needed to be addressed:
•• Resolving differing viewpoints from a large number of member companies
and participants.
•• Describing the architecture in a manner that provided enough technical
guidance to contributors working on the follow-on implementation, but
could still be comprehended by non-technical stakeholders such as those in
marketing, and also by usability experts.
“A comprehensive set of standard
architecture principles was selected,
and referenced terms were defined
(for example, extensibility, portability,
time to market, and scalability).”
The first challenge was solved in large part by following a relatively simple
process: a comprehensive set of standard architecture principles was selected,
and referenced terms were defined (for example, extensibility, portability, time
to market, and scalability). The team came to the realization that the system
architecture could look quite different, depending on how these principles
were prioritized, so each member company furnished a prioritized list that
effectively served as their ballot. The lists were compiled, and the resulting
unified prioritized list of architecture principles served as a useful tool during
architecture sub-team meetings where various design alternatives and tradeoffs
were discussed.
The second challenge primarily arose from the fact that the team needed
to create a logical view of the system architecture composed of logical (or
functional) components, but it was much easier to describe concepts to a nontechnical audience in terms of physical components (for example, a weight
scale or a personal computer). The solution in this case was to create a hybrid
view of the architecture that represents both logical and physical entities, as
shown in Figure 1.
Application Hosting Device
Control Application
Service Virtualization Middleware
PAN Client
Component
In the following subsections we look more specifically at the architecture
depicted in Figure 1.
PAN Interface
Personal Area Network Devices
A personal area network (PAN) device is a real-world physical device that a
person interacts with to obtain a measurement, for example. Examples of PAN
devices include blood glucose meters, weight scales, and pedometers. Note that
the term PAN device is synonymous with the term agent introduced later in the
Implementation section.
PAN Service Component
A PAN device must contain a PAN service component. This is a logical
component that offers one or more services over the PAN interface.
PAN Service
Component
PAN Device
Physical Device
Logical Component
Figure 1: Continua Device Architecture
Source: Continua Health Alliance, 2009
Application Hosting Device
An application hosting device is a physical device that communicates with
one or more PAN devices to receive measurements, for example. Examples
of application hosting devices include purpose-built, healthcare appliances,
personal computers, and cell phones. Note that the term application hosting
device is synonymous with the term manager introduced further on in the
Implementation section.
PAN Client Component
An application hosting device must contain a PAN client component. This is a
logical component that consumes one or more services over the PAN interface.
Service Virtualization Middleware
Service virtualization middleware is a logical component that normalizes
details associated with a number of PAN client components, such that control
applications can consume PAN services from a wide variety of devices in a
consistent fashion. For example, if a system has two PAN devices, a Bluetooth
blood-pressure monitor and a USB weight scale, control applications would
receive measurements through the unified interface offered by the virtualization
middleware without requiring detailed understanding of the specific transport
technologies involved.
“Examples of application hosting
devices include purpose-built,
healthcare appliances, personal
computers, and cell phones.”
Control Applications
Control applications consume the interface implemented by the service
virtualization middleware to communicate with a wide variety of PAN service
components.
PAN Interface
PAN
Device
1…*
1
Application
Hosting Device
1
1
1…*
1…*
PAN Service
Component
1
1
Physical Device
PAN Client
Component
Logical Component
The PAN interface is the standards-based communication interface between
PAN service components and PAN client components that enables device
interoperability in the Continua Health Alliance ecosystem.
Figure 2 shows the multiplicity of relationships between the various
components that make up the Continua device architecture. A PAN device
contains one or more PAN service components. An application hosting device
contains one or more PAN client components. There is a one-to-one
relationship between PAN service components and PAN client components.
There is a one-to-many relationship between an application hosting device and
a PAN device.
Figure 2: System Multiplicity
We now move on to describe how the PAN interface was realized during the
implementation phase of the Continua Health Alliance development process.
Implementation
There are multiple standards that are utilized when implementing the PAN
solution. Figure 3 depicts the standards and their relationships.
Continua Design Guidelines
Device Specialization Layer
Higher
Layer
Protocol
Lower
Layer
Protocol
04 – Pulse
Oximeter
07 – Blood
Pressure
08 – Thermometer
15 – Weighing
Scale
17 – Glucose
Meter
19 – Insulin
Pump
21 – Peak Flow
+Phase III
41 – Cardiovascular Fitness & Activity
42 – Strength Fitness Equipment
71 – Independent Living Activity Hub
72 – Medication Monitor
Optimized Data Exchange Protocol Layer
ISO/IEEE Std 11073–20601
Transport Layer
Bluetooth* Health
Device Profile
USB Personal
Healthcare Device
Figure 3: Standards for PAN Interface
Source: Continua Health Alliance, 2009
ZigBee* Personal
Healthcare Device
The higher-layer protocols are standardized by the International Standards
Organization (ISO) and the Institute of Electrical and Electronics Engineers
(ISO/IEEE). The higher-layer protocols consist of a common, optimized data
exchange protocol that provides a broad toolbox of interactions in support of
any type of device. The highest-layer protocols are specializations that tailor
the usage of the toolbox to specific device types (such as to a weighing scale) in
order to maximize interoperability between the device sensing the health data
and the one receiving the data. Each of the device specializations begins with
ISO/IEEE Std 11073-104zz where zz is the two digit number in each of the
boxes in Figure 3.
“The highest-layer protocols are
specializations that tailor the usage of
the toolbox to specific device types.”
The lower transport layers are specified in other organizations such as Universal
Serial Bus (USB) Implementers Forum, Bluetooth Special Interest Group
(SIG), or ZigBee* Alliance. However, the IEEE Personal Health Device (PHD)
work group has worked closely with the other organizations to harmonize the
application levels with the transport levels.
As a backdrop to all the standards, the Continua Health Alliance produces
design guidelines that further clarify and if necessary, narrow optionality to
increase interoperability. Again, there is a close working relationship between
Continua Health Alliance membership and all the standard organizations and
special interest groups.
Principles of Implementation
When initially creating the IEEE standards, the PHD work group surveyed
existing devices to understand the needs in the market.
“One key goal was to support a broad
range of device types that fit within
one or more of these categories: health
and wellness, disease management,
and independent living.”
One key goal was to support a broad range of device types that fit within one
or more of these categories: health and wellness, disease management, and
independent living. To do this, it was felt that a common exchange protocol
was necessary to allow a single manager (for example, health appliance, settop box, personal computer, cell phone) to accept data from a broad range
of device types such as glucose meters; fitness equipment; and home sensors,
such as motion sensors, light sensors, and gas sensors. At the same time, since
the sensing agents often run on small batteries, efficient transmission of the
data is also paramount. IEEE Std 11073-20601-2008 attempts to balance the
architecture between these two goals so that it is flexible enough and yet has
optimized packet sizes.
In order to optimize data exchange, the IEEE Std 11073-20601 has three
different event-reporting formats that range from very flexible (but bigger)
to very compact (but less flexible). In the very compact forms, all of the
information about what the bytes mean is extracted and sent once during
configuration. This allows the event reports containing the health data to
report primarily just data and remove redundant bytes of meta-data.
“At the same time, since the sensing
agents often run on small batteries,
efficient transmission of the data is
also paramount.”
“When there was a choice between
placing a feature on the sensing agent
or on the manager, the feature should
be placed on the manager.”
An overarching principle when creating the standards was that when there was
a choice between placing a feature on the sensing agent or on the manager, the
feature should be placed on the manager. This choice helps to keep the cost of
building agents as low as possible. Therefore, in general, the agent is “in charge”
and determines when it has data, when it wants to transmit those data, and
what functionality it selects to expose. The manager must adapt to the agent.
Due to the range of device types, the standards need to support three different
styles of data delivery: episodic – data delivered based on an action, such as
stepping on a scale; periodic – the device sends data at a known frequency, such
as updating the blood oxygen saturation every second; and store and forward –
the device collects data while not connected to the manager and then the data
can be uploaded on a later connection, such as when a person walks with a
pedometer for an exercise session. Thus, there is a range of tools in IEEE 1107320601 for supporting these modes of data transfer.
“Our design goal from the outset
was to keep the higher-layer protocol
independent from the transport layer.”
Our design goal from the outset was to keep the higher-layer protocol
independent from the transport layer. There are several reasons for this
independence. First, we recognized that some use-cases were best supported
with a wired transport, and others were better supported with a wireless
transport. Second, transport technology continues to advance, so it is
advantageous to adopt new transports as they become available. Third, by
utilizing a common application layer, the transport details can be abstracted
deep within a software stack, allowing most of the upper portions of software
to be re-used, regardless of which transport is used.
Another big difference between the PHD standards and other healthcare
standards is that PHD standards focus on personal health in the home and
mobile environments. Such a focus allows for a reduction in complexity. For
instance, when blood pressure is measured in the home, there is a limited set
of ways it is measured (for example, it is measured non-invasively on the arm
or wrist); whereas, in a clinical setting, there are additional ways it could be
measured (for example, invasively across heart valves or by measuring umbilical
pressure). By focusing on the needs of home health devices only, the standards
process is less complex, and implementations are easier to build, test, and make
interoperable. In addition, solutions can meet the price points required by the
consumer market.
Common Optimized, Data-Exchange Protocol
“By focusing on the needs of home
health devices only, the standards
process is less complex, and
implementations are easier to build,
test, and make interoperable.”
Within the IEEE Std 11073-20601 there are five major elements as shown in
Figure 4. We describe these elements in detail in the following sections.
1. Abstract Syntax Notation.1 (ASN.1). Language used in the abstract modeling
of data and interactions.
2. Nomenclature. Provides binary codes for terminology.
3. Domain Information Model (DIM). Describes the device and physiological
data.
4. Service Model. Defines interactions with the device and data.
5. Communication Model. Manages the connection state machine and
communication characteristics.
Abstract Syntax Notation
Abstract Syntax Notation.1 (ASN.1) is an existing standard for describing
concepts in an abstract notation that is independent of an underlying
implementation language.
ISO/IEEE Std 11073–20601
ASN.1
Domain Information Model
Nomenclature
Service Model
Communication Model
By using ASN.1 to describe the modeling of the Domain Information and
Service Models, it is possible to generate code automatically for different
computer languages as well as code that converts from internal data structures
into different transmission representations (such as binary or XML).
Figure 4: Components of IEEE Std 11073-20601
Source: IEEE, 2008
Nomenclature
The nomenclature represents binary values that are used to describe,
unambiguously, the concepts being modeled. For example, there are separate
codes for pulse rate, heart rate, systolic blood pressure, and diastolic blood
pressure. By defining specific codes for all the concepts being modeled, two
devices are able to exchange information by using a common language.
By using binary codes rather than strings, the nomenclature also aids in
supporting localization efforts so the concepts can be represented to the
operator in the local language.
The Domain Information Model
The Domain Information Model (DIM) contains objects that represent both
device-level information (for example, battery status, current time, model and
serial number), physiological information (for example, weight, blood pressure,
number of steps), and environmental information (for example, gas or water
left on, house too cold or too hot). The DIM uses object-oriented concepts
in specifying the model. This eases the maintenance and modeling effort for
standard creation. There is no requirement to implement the model by the use
of object-oriented languages and, in fact, there are product implementations
built by using Standard C.
The object classes that are available are generic in nature in order to support
a wide range of usages. There are currently classes of objects to describe the
device itself (for example, battery or wall-powered device), numeric objects (for
example, physiological measurements such as temperature), real-time sample
arrays (for example, usually for waveforms such as an ECG), and enumerations
(for example, at this time the door was opened). There are also classes that
support the storing and forwarding of measurements and scanners that assist in
compacting data streams.
Each class defines the object type, the standardized attributes (variables)
available in the class, and the actions (methods) that can be executed for
objects of the class. The agent represents its data by creating one or more
objects and then communicating the starting values of the attributes. As data
changes, the agent sends event reports to the manager to inform it of the
changes.
“By defining specific codes for all the
concepts being modeled, two devices
are able to exchange information by
using a common language.”
“The Domain Information Model
(DIM) contains objects that represent
both device-level information,
physiological information, and
environmental information.”
“Attributes of an object are set by
the agent to represent the current
conditions.”
Attributes of an object are set by the agent to represent the current conditions
(for example, there is an observed value attribute that defines the person’s
weight and another that describes the unit-code for pounds or kilograms).
Attributes have qualifiers in the standard that describe whether the attribute
is: a) mandatory, that is, it must be present, b) conditional, that is, if the
condition is met, it is mandatory; otherwise, it is optional, or c) optional, that
is, where the agent implementers determine whether they want the attribute
in their product. In addition, additional attributes can be added to an object
beyond those that are standardized. This allows vendors to model other items
to differentiate their product, if desired.
Service Model
The service model describes the services that are available for communicating
data to and from the agent. There are three categories of services:
•• Event reporting. This is used by the agent to send updates to the manager
about its configuration or any new measurements that are available.
•• Object access. This is used by the manager to get, set, or invoke actions on
the agent.
•• Association. This is used by agent and manager to create an association
with one another so they are synchronized on their operational and
communication state.
Communication Model
The communication model is the abstraction between the upper application
layers and the transport layers. The key items that are described in the
communication model include the following:
•• Communication characteristics. While it would be nice to be agnostic to the
underlying transport, there are certain requirements that the applicationlevel protocol requires of transports. These are described to make it easy to
assess whether a transport can work natively or if a shim is required to make
the transport conformant.
•• Connection state machine. This describes the states that a manager and agent
move through during an association. The agent’s state diagram is shown in
Figure 5.
•• Legal interactions in each state. These describe the actions that are and are
not allowed while in each state of the state chart.
•• Conversion service. This describes the method required to convert from
the ASN.1 modeling into a transmission format encoding. The standard
supports three different styles of encoding, but it mandates that the most
basic one shall always be present to ensure the agent and manager can
interoperate at an encoding level.
Disconnected
Transport connect
indication
Transport disconnect
indication
Connected
Disassociating
Associated
assocRelReq
Operating
+entry/TxAssocRelReq
TxAssocAbort
RxAssocAbort
RxAssocRelRsp
RxAssocRelReq/
TxAssocRelRsp
Unassociated
TxAssocAbort
Configuring
RxAssocAbort
RxAssocRelReq/
RxConfigEventReportRsp
(accepted-config)
TxAssocRelRsp
Waiting Approval
assocReq
RxAssocAbort
Or
TxAssocAbort
RxAssocRsp
(accepted)
RxAssocRsp
(rejected)
RxConfigEventReportRsp
(unsupported-config)
Associating
+entry/TxAssocReq
TxConfigEventReportReq
RxAssocRsp
Sending Config
(accepted-unknown-config)
Figure 5: Agent State Diagram
Source: IEEE, 2008
Example Device Specialization (Glucose Meter)
Figure 6 shows the glucose meter modeling. To be conformant, the only
mandatory objects are the glucose reading and the object representing the
device. However, many glucose meter models available today allow the user
to enter additional contextual data that helps when interpreting a reading.
For example, did the person exercise? Did the person eat a meal recently? Was
medication taken near the reading? The optional objects of the glucose meter
standard allow a vendor to model this type of context data. Finally, there is a
persistent metric store that allows the device to store readings for a longer time,
such as the time between doctor visits.
PHD-Glucose meter object instances
Glucose: Numeric
Observations: PM-Store
Glucose Meter: MDS
1
1
1
0…1
1
ContextExercise: Numeric 0…1
ContextDiet: Numeric 0…1
ContextMedication: Numeric 0…1
ContextHbA1C: Numeric 0…1
0…1 ContextHealth: Enumeration
0…1 EventDeviceErr: Enumeration
0…1 ContextMeal: Enumeration
0…1 ContextSampleLocation: Enumeration
0…1 ContextTester: Enumeration
Figure 6: Glucose Meter Modeling
Source: IEEE, 2009
Transport
“This specification takes into
consideration personal health wired
requirements and defines a mechanism
to exchange data between devices over
USB.”
consideration personal health wireless
PAN requirements and defines a
mechanism to exchange data between
devices over Bluetooth.”
The Continua architecture separates the transport from the protocol, data, and
nomenclature. This abstraction allows for various transports to be leveraged
as usage requires without impacting the upper-layer applications. As of this
writing, there are three different transport technologies available and the
specification used for each one is explained next.
USB
If a wired transport is desired, then the USB Personal Healthcare Device
Class (PHDC) specification has been selected. This specification takes into
consideration personal health wired requirements and defines a mechanism
to exchange data between devices over USB. The USB Implementers Forum
has an automated test tool that is in place to provide USB Personal Healthcare
Device class transport certification of personal health devices.
Bluetooth
If a wireless transport is desired for point-to-point personal area network
connectivity, then the Bluetooth Health Device Profile specification has been
selected. This specification takes into consideration personal health wireless
PAN requirements and defines a mechanism to exchange data between devices
over Bluetooth. The Bluetooth SIG has an automated test tool that is in place
to support a Bluetooth transport certification of personal health devices.
If a low-power version is necessary (for example, extreme sensitivity to battery
life), then the Bluetooth Low Energy (LE) specification has been selected.
This technology is anticipated to be combined with classic Bluetooth on the
aggregation device in order to accept input from either HDP or LE.
ZigBee
If a low-power wireless transport is desired for local area network
connectivity, then the ZigBee Health Profile specification has been selected.
This specification takes into consideration personal health wireless LAN
requirements and defines a mechanism to exchange data between devices over
ZigBee. The ZigBee Alliance has a tool in place to support a ZigBee transport
certification of personal health devices.
mechanism to exchange data between
consideration personal health wireless
LAN requirements and defines a
devices over ZigBee.”
Lessons Learned
To enable the personal health market during the development of the Continua
Health Alliance over the past three years, several key lessons have been learned.
We discuss several of the important ones.
•• Start out with market-viable use-cases and requirements. It is easy to let
technology lead the way for a particular use-case, but it is imperative to
ensure that there is broad market support (i.e., more than one company)
and that the purchasers and domain experts are involved in the definition
process such that what is eventually delivered is relevant.
•• Carefully constrain scope and ensure appropriate focus. As the number of
companies in an organization grows so does the appetite for new, complex
capabilities, and it is easy to get distracted and lost. Since there are limited
resources, it is important that the highest-priority capabilities are identified
and that they become the main focus of the organization.
•• In order to avoid confusion, it is important to agree on the philosophical
positions of the organization ahead of time. These include choices, such
as whether to profile by developing guidelines, or try and augment the
standards; or whether to focus on simplicity (basic features) instead of
complexity (rich features).
Conclusion
As a result of the potential benefits of home-based healthcare, a growing
number of companies have focused their efforts on developing telehealth
solutions in the personal healthcare domain. While there are a number of
challenges that must be addressed for this endeavor to be successful on a large
scale, excellent progress has been made toward the removal of one key obstacle:
personal health device interoperability.
“Excellent progress has been made
toward the removal of one key
obstacle: personal health device
interoperability.”
The efforts of the Continua Health Alliance and standard development
organizations, such as the USB IF, Bluetooth SIG, and IEEE, have culminated
in a set of standards that specify the manner in which personal health devices
communicate as well as in design guidelines that profile these standards,
thereby removing ambiguity and ensuring true interoperability.
Armed with these design guidelines and standards, device vendors, software
developers, service providers, integrators, and purchasers are now in the
position to focus on their respective areas of expertise and collectively deliver
on the vision of home healthcare delivery based on systems composed of
interoperable personal health devices.
Reference
[1]
Continua Health Alliance. Available at www.continuaalliance.org.
Author Biographies
Doug Bogia is a Standards Architect in Intel’s Digital Health Group. In 1995,
Doug received his Ph.D. from the University of Illinois, Urbana-Champaign
in Computer Supported Collaborative Work. Since joining Intel in 1995,
Doug has held a number of positions ranging from implementing collaborative
business and personal products, to implementing small business support
services, to creating telecommunication products. During 2002, he assisted in
creating the Advanced Telecom Computing Architecture standard enabling the
telecommunications industry to begin interoperable implementations in 2003.
In 2005, he shifted focus to the healthcare industry. Doug led the formation of
the ISO/IEEE 11073 Personal Health Devices Work Group where he currently
serves as the Work Group Chair. He is also an active participant in the
Continua Health Alliance, Bluetooth Medical Devices Work Group, and USB
Personal Health Device Profile. His e-mail is Douglas.P.Bogia at intel.com.
Rick Cnossen is the President and Chairman of the Board for the Continua
Health Alliance. Continua is a large, international, cross-industry consortium,
focused on the establishment of an ecosystem of interoperable, personal
telehealth systems. He is also a Director of Personal Health Enabling for
Intel’s Digital Health Group with a focus on medical device interoperability
standards. Additionally, he serves on the HITSP Board of Directors and is a
participating member of the ISO/IEEE 11073 Personal Health Data Work
Group, the HITSP Consumer Perspectives Technical Committee, the Health
Level Seven (HL7) Structured Document Technical Committee, the USB
Personal Health Device WG, and the Bluetooth Medical Device Profile WG.
Mr. Cnossen holds an MSCS degree from the University of Southern
California (USC). He worked at McDonnell Douglas (Boeing) for 15 years as
a Software Engineering Manager on a variety of aerospace and defense projects
and at Intel Corporation for 9 years as an Engineer Manager and Director.
During this time, he has been involved in many industry technology and
standards development efforts including the Advanced Telecommunications
Architecture (ATCA) manageability specification, Tactical Defense data
collection and analysis, Hierarchical Data Assimilation and Storage, and High
Performance Computing. His e-mail is rick.a.cnossen at intel.com.
Chris Gough is an Enterprise Architect with the Product Development team
in Intel’s Digital Health Group. Prior to his focus on product development,
Chris was closely involved with the Continua Health Alliance Technical Work
Group and had a key role in developing the Continua system architecture.
Chris joined Intel in 1991 and, prior to his tenure with the Digital Health
Group, has held various technical positions in the Digital Enterprise Group
focusing on motherboard design applications and validation tools, emerging
networking technologies, and systems architecture. Chris holds a bachelors
degree in Computer Science and Engineering from the University of California
at San Diego. His e-mail is chris.s.gough at intel.com.
Copyright
countries.
A Common Personal Health Research Platform — SHIMMER™
and BioMOBIUS™
Contributors
Michael J. McGrath, Ph.D.
Intel Corporation
Terrance. J. Dishongh, Ph.D.
Intel Corporation
Index Words
Research Platform
BioMOBIUS™
SHIMMER™
Sensing
Extensible
Flexible
Abstract
As the cost of healthcare continues to rise, and the aging population
demographic in the Western world continues to increase, the pressure on direct
clinical resources continues to grow at an alarming rate. The health of people
around the world is worsening and the global population is getting older.
With this in mind the goal of SHIMMER™ (Sensing Health with Intelligence,
Modularity, Mobility and Experimental Reusability) systems is to provide an
extremely compact extensible platform for body-worn or ambient sensing
applications based on connected or disconnected data strategies with proven
system building blocks. Additionally, to aid in the analysis of the data coming
from SHIMMER, it is fully integrated with the software environment of the
BioMOBIUS™ research platform. The combination of the BioMOBIUS and
SHIMMER platforms give researchers an extensible and flexible systems that
can be utilized to rapidly develop prototype research tools to acquire data in
a reliable and timely manner. In this article, we outline how the combined
BioMOBIUS and SHIMMER platforms can be used to develop sophisticated
research tools.
Introduction
“The technology development overhead
that many biomedical researchers
must address can detrimentally impact
the pace and scope of the research
projects.”
Biomedical and clinical research and development projects have a growing
need for technology solutions that are highly flexible, extensible, easy to use,
and provide a comprehensive range of capabilities. The availability of such
resources allows researchers to focus on the R instead of the D in R&D during
the lifecycle of their research project. The technology development overhead
that many biomedical researchers must address can detrimentally impact the
pace and scope of the research projects. This problem has been compounded
in recent years due to the growing interest in moving from laboratory to data
collection and observation in home environments. A variety of applications
have been reported in the literature including physiological monitoring [1-3],
physical rehabilitation [4], activities of daily living (ADL) monitoring [5, 6],
falls detection [7, 8], cognitive function [9], and social engagement [10, 11].
These applications typically comprise hardware and software components
interconnected to form customized applications to address the needs of a
specific research hypothesis.
122 | A Common Personal Health Research Platform — SHIMMER™ and BioMOBIUS™
Many biomedical applications utilize wireless sensing capabilities in the form
of body-worn sensing or non-contact sensing to acquire data of interest and
to transmit them to an aggregation device. Fusion of both body-worn and
ambient sensors has been reported to improve accuracy of inference based on
activity or behavior identification [12, 13]. Typically, multiple parameters are
of interest including physiological [14, 15], kinematic [16, 17], ambient [18,
19], and environmental measurements [20].
To address the need for multisensing capabilities while minimizing the
complexity of the hardware and software components, platform-based
approaches have emerged where the sensing capability of the sensors can
be modified by changing the sensing element, normally in the form of a
daughterboard that connects to a common baseboard that provides the
computational and communications capabilities. Chen et al [2] report a
sensor node platform for wireless biomedical sensing. They utilize a flexible
expansion connector that supports additional daughterboards, including ECG
with TinyOS* firmware. DuboisFerrière et al [21] describe the TinyNode*,
which features two types of add-on boards. The Standard Extension Board
(SEB) includes footprints for two optional sensors: a relative humidity
and temperature sensor and a photodiode light sensor. The MamaBoard
features a variety of external communications including, LAN, WLAN, and
GPRS options with support for data storage via an SD card. The platform
also features an XE1205* from Semtech with a reported four- to eightfold communications range performance improvement over MICA2 and
TelosB sensor nodes. Nokia has reported a wearable sensor platform called a
Nokia Wrist–Attached Sensor Platform* (NWSP) that is based on a highly
flexible Field Programmable Gate Array (FPGA) [22]. The platform features
an accelerometer, a gyroscope, and magnetometer sensing capabilities in a
wristwatch-like form-factor.
“Typically, multiple parameters are
of interest including physiological,
kinematic, ambient, and
environmental measurements.”
“Platform-based approaches have
emerged where the sensing capability
of the sensors can be modified by
changing the sensing element.”
For a body-worn sensor platform, size is a key consideration. IMECs
Human++ research program has developed a highly miniaturized and
autonomous sensor system for body sensor network applications [23]. The
platform combines wireless ultra-low power communications, 3D integration,
MEMS energy scavenging techniques, and low-power design techniques.
Two-channel Electroencephalography (EEG), two-channel Electrooculography
(EOG), and one-channel Electromyography (EMG) for sleep-monitoring
applications and wireless ECG monitoring have been demonstrated [24].
From a software perspective, platforms for wireless sensor networks have been
reported in the literature [14, 25, 26]. Walker et al describe a Java* and Java
Agent based Development (JADE) platform; it is designed to provide sensor
network integration and application development capabilities [27]. Other Java
platforms include SunSPOT* from Sun Microsystems [28].
“For a body-worn sensor platform, size
is a key consideration.”
A Common Personal Health Research Platform — SHIMMER™ and BioMOBIUS™ | 123
“Both the C-type programming and to
a lesser extent the SDK approaches are
complex and time-consuming.”
“The environment can cater for users
with widely varying levels of technical
expertise by enabling design and
development work to be carried out at
several levels of abstraction.”
“LabVIEW provides a GDE with
a drag and drop capability for
functional blocks wired together to
The Arduino* open-source electronics prototyping platform has become
popular (www.arduino.cc) especially for under-graduate teaching purposes. A
number of research applications have been reported, including e-Textiles*, that
are based on the integration of accelerometers for motion capture and human
motion capture in combination with tactile feedback in response to specific
postures in real-time [29, 30].
A number of options exist for high-level application program development
with associated benefits and difficulties. Typically there is a choice between
traditional syntactically-oriented software languages such as C/C++, Java,
Python*, etc., bespoke software development environments (SDKs); e.g.,
Eclipse*, and graphical development environments (GDE). Both the C-type
programming and to a lesser extent the SDK approaches are complex and
time-consuming. Firstly, they often result in applications that are harder
to debug, integrate, and evolve. Secondly, they restrict researcher access to
the development process. Graphical programming approaches can deliver a
common interface to the sensor/network with which all users will be able to
interact. These interfaces generally take the form of drag and drop development
environments where functional blocks are selected from a palette of tools
and connected on a drawing area to describe data flow through a system or
application. The environment can cater for users with widely varying levels
of technical expertise by enabling design and development work to be carried
out at several levels of abstraction. Using a GDE, a developer can build a
working system graphically by dragging and dropping blocks onto a diagram
(resembling a data-flow diagram). Typically, each block features a number of
input and output pins, with connections made between blocks by clicking and
dragging from a pin on one block to a suitable pin on another block.
LabVIEW* from National Instruments, has been popular for many years,
particularly for applications that required data acquisition via an analog-todigital converter (ADC) or device actuation via a digital-to-analog converter
(DAC). LabVIEW provides a GDE with a drag and drop capability for
functional blocks wired together to form a functional application. It has
been used for a variety of biomedical-type applications including interfacing
pulse oximeters [31], ECG signal analysis [32], tri-axial accelerometers and
galvanic skin response (GSR) [33], and gyroscopes for gait analysis [34]. Other
graphical programming environments that have been developed for biomedical
applications include Scicos: these can be utilized for signal processing,
systems control, and for studying physical and biological systems [35]. The
BioEra* environment provides a graphical block-based environment that can
process dozens of channels simultaneously in real-time from various devices,
including EEG and heart rate monitors [36]. BrainBay* is a bio- and neurofeedback environment, again based on a block-type development environment
designed to work with the OpenEEG*-hardware platform [37]. Simulink*
from MathWorks provides an interactive graphical environment that has been
applied to a variety of sensor simulation applications [38, 39].
form a functional application.”
In order to address the issues associated with technology development such
as rapid prototyping, reuse, extensibility, distribution, etc., the TRIL Centre
[40] has developed a modular, extensible, and reusable technology approach
based on an open research platform concept called BioMOBIUS. The TRIL
Centre is a collaboration between Intel Ireland, University College Dublin,
Trinity College Dublin, and the National University of Ireland at Galway, with
support from IDA Ireland. TRIL grounds its research in ethnography and
clinical efficacy, with a common set of research tools based on BioMOBIUS,
and takes the research out of the lab into homes of older people. BioMOBIUS
enables TRIL researchers to carry out their research in an effective and
efficient manner and to have the ability to share their research solutions in
a logistically effective manner. A modular, abstracted approach reduces the
learning curve and prompts rapid application prototyping and reuse, thereby
lowering development costs and reducing the barriers to technology adoption.
The software components of BioMOBIUS are made freely available to the
biomedical research community by the TRIL Centre.
“TRIL grounds its research in
The BioMOBIUS research platform comprised of both low-level and
high-level software development environments is fully integrated with the
SHIMMER sensor platform [41, 42]. BioMOBIUS also supports a number
of other third-party sensors and off-the-shelf devices. This integration of
software and hardware provides a unique set of capabilities that enables
developers, engineers, and researchers to rapidly develop research applications
to investigate a variety of research hypothesis and to rapidly modify the
applications based on the evolving needs of the researcher and end user. The
key features of the platform to enable such capabilities are as follows:
“The BioMOBIUS research platform
ethnography and clinical efficacy, with
a common set of research tools based
on BioMOBIUS.”
is fully integrated with the
SHIMMER™ sensor platform.”
•• Ease of hardware integration.
•• Software component reuse.
•• Highly extensible both from a hardware and software perspective.
•• High quality user interfaces (UI).
•• Supports data acquisition rates appropriate for kinematic and physiological
data capture.
•• Provides real-time data processing and data presentation.
•• Data persistence to file and database.
•• Stability and reliability.
•• Supports rapid application prototyping, i.e., short development times in
the order of one to two weeks.
A typical BioMOBIUS application includes SHIMMER sensors, processing
functionality, and a UI. The sensors monitor biomedical indicators such as
gait stability, and the processing functionality converts the sensor data into
meaningful information. The UI allows clinicians to view the information and
adjust the application settings or it allows the home-based participant to view
feedback information on performance; e.g., attention level measurement via
GSR.
“A typical BioMOBIUS application
includes SHIMMER sensors,
processing functionality, and a UI.”
BioMOBIUS Software Environment
“Originally focused on visual arts
applications, EyesWeb provides fusion
of motion and music for emotion
capture during artistic performance.”
Drag and drop environments ideally support the concept of rapid application
prototyping through the development of applications, by selecting blocks from
a palette of capabilities categorized by function, such as input/output, data
management, digital signal processing (DSP), etc. Sophisticated applications
can be quickly assembled, including hardware interfacing and real-time data
processing, by using the functional blocks that are connected in sequence to
represent the real-time data flow.
EyesWeb*, developed by the University of Genoa, was selected as the drag
and drop GDE [43, 44]. Originally focused on visual arts applications,
EyesWeb provides fusion of motion and music for emotion capture during
artistic performance [45]. It is also utilized to develop applications based on
multimedia techniques for therapy and rehabilitation; e.g., Parkinson’s, Autism
[46, 47]. The EyesWeb software platform was originally developed in EU 5th
Multisensory Expressive Gesture Applications (MEGA, see www.megaproject.
org) and 6th Framework Programme, the Tangible Acoustic Interfaces for
Computer Human Interaction (TAI-CHI). The EyesWeb environment has
been adapted and enhanced by TRIL for biomedical oriented applications as
shown in Figure 1.
“The EyesWeb environment has been
biomedical oriented applications.”
BioMOBIUS High Level Application Development Env
adapted and enhanced by TRIL for
BioMOBIUS
Applications
BioMOBIUS
GUI Designer
Applications
Applications–
Physiological, Kinematic
User Interface
RCF Interface
EyesWeb
IDE
DSP
Image
Services
Database
Services
Protocols
File
Services
Math
Operations
Sensor
Services
Audio/Video
Services
EyesWeb Kernel
Firmware
Windows API’s
Hardware
Interfaces
BT
Stack
Driver
Hardware
X10
Stack
Driver
Hardware
USB/
RS232
Stack
Driver
Hardware
Figure 1: BioMOBIUS Architecture
Source: The TRIL Centre (www.trilcentre.org)
IEEE
802.15.4
Stack
Driver
Hardware
ThirdParty
Applications
e.g. Databases
The EyesWeb environment comprises a GDE that supports drag and drop
application development in the form of patches. BioMOBIUS provides a
Graphical User Interface (GUI) development tool that enables the user
to design an application to control a patch and view its output. The GUI
Designer is built by using the JUCE* C++ class library [48]. This is a crossplatform, high-level, graphical application program interface (API) and
provides the potential to develop BioMOBIUS applications on non-Windows*
platforms.
“The EyesWeb environment comprises
a GDE that supports drag and drop
application development in the form
of patches.”
Use of the GUI development tool allows the user to be abstracted away from
the underlying complexities of the connected patch. The resultant application
is called a GUI application. The runtime environment within BioMOBIUS
comprises two key components:
•• Kernel Runtime Server. The EyesWeb Kernel Runtime is a Windows
component that supports the execution of EyesWeb patches outside of the
EyesWeb GDE. It is used in conjunction with the BioMOBIUS Runtime
to execute GUI applications and patches as if they are native Windows
applications.
•• BioMOBIUS GUI Runtime. This is a Windows console application that
supports the execution of a BioMOBIUS application outside of the GUI
development tool. Typically, a BioMOBIUS application is first developed
and tested within the GUI development tool. Thereafter, the BioMOBIUS
Runtime is used to run the application as a Windows executable in
conjunction with the EyesWeb Kernel Runtime component, via a TCP/IP
connection that supports execution of the patch and GUI on two physically
separated networked systems, if required.
Both patches and GUI applications are defined in XML and interpreted by
their respective runtimes. A number of benefits are achieved by separating these
two frameworks:
•• Runtime efficiency. Applications consume less system resources; for example,
output and display rendering is automatically disabled in the runtime
environment.
•• Separation of duty. Patches and UI applications may be developed in
parallel.
•• Distribution. An application and its patch may execute on separate
platforms across a network.
•• Extendibility. Other graphical development environments may be used to
develop feature-rich applications such as FLASH-based interfaces.
“Both patches and GUI applications
are defined in XML and interpreted
by their respective runtimes.”
Output
pin
x
t
Input
pins
Blocks
Blocks, as shown in Figure 2, are the fundamental building units of the
environment which are dragged and dropped onto a patch from a palette of
blocks grouped by functionality. A block is coded as a C++ class with inherited
attributes and methods. The number of inputs and outputs for each block is
determined by the developer during the development process. Inputs and
outputs are referred to as pins. There are two categories of inputs:
Figure 2: BioMOBIUS block with input and output
•• Main inputs (block receives its primary data for processing).
pins
•• Parameter inputs (configuration details determines block execution).
Blocks are executed in two ways at runtime. Active blocks initiate their own
execution by requesting the kernel to schedule its execution. Initiation of
execution is triggered periodically by using kernel polling, i.e., a call-back
mechanism. The second type of execution is used by reactive blocks. These
blocks are executed by the kernel when data arrives at its main input. The
kernel is alerted to the availability of these data by a system flag in the block
setting.
+
GUI
+
E
+
+
+
+
+
+
+
+
+
GUI Objects
Kernel
Legacy
Steinberg Technologies
Base
System
National Instruments
3D
BioMOBIUSBiosignals
BioMOBIUSBase
BioMOBIUSHardwareIO
BioMOBIUSMath
Catalog View
+ GUI
+
+
+
+
+
+
+
+
+
+
+
+
+
+
GUI Objects
Math
Audio
BioMOBIUS
DataStructures
Filesystem
FlowAndControlStructure
Geometric
ImageAndVideo
Math
Operations
Peripherals
String
TimeAndDate
TimeSeries
New blocks can easily be developed for the GDE by using the EyesWeb
software development kit (SDK) and integrated development environment
(IDE) wizards. Typically, a user creates a new block to support a new hardware
device or execute a specific DSP function. In addition, EyesWeb applies
data-type checking on block data pins, and the SDK supports the creation of
user-specific data types. The developer of a new block has the choice to either
distribute the source and/or binary to the development community.
Blocks are organized in two ways with the GDE. Firstly, they can be aggregated
into catalogs that are physical collections of blocks within a standard Windows
environment. Secondly, they can be structured into libraries which are logical
collections organized according to functionality/use; e.g., mathematical
operations (Figure 3).
Patches
In order to build a functioning application, blocks are dragged from libraries or
catalogs in the GDE environment and connected together to form a patch. A
patch comprises a series of blocks linked together in order of execution to form
a fully-functional application. Figure 4 shows an example of a patch designed
to allow the user to manually trigger the acquisition of data from a SHIMMER
sensor, process the received data, and to display the acceleration values sensed
by the sensor to the user. A patch is executed via the Kernel Runtime Server.
The EyesWeb Kernel Runtime is a Windows component that supports the
execution of EyesWeb patches both inside and outside the EyesWeb GDE.
Library View
Figure 3: Library and catalog views within the
BioMOBIUS GDE
CONNECT
START
x
STOP
t
DISCONNECT
x
t
Shimmer
x
t
Figure 4: Sample patch using SHIMMER in the EyesWeb GDE
As the complexity of an application increases so too does the need to
structure patch development into logical or functional units. Complex
patch development can be managed through the use of the subpatch feature
within the EyesWeb environment. The subpatch supports the integration of
a functional group of interconnected blocks into a single block-like subpatch
structure.
“BioMOBIUS features a variety of
digital signal-processing capabilities.”
Digital Signal Processing Capabilities for Biosignal Processing
BioMOBIUS features a variety of digital signal-processing capabilities. For
real-time video processing, an extensive range of processing options exists
including, baricenter/centroid calculations, quantity of motion from a
silhouette, background subtraction, image concatenation, and image splitting.
A variety of more advanced techniques is also available including real-time,
full-body motion tracking and blob extraction. Time domain digital filtering
is served by Finite Impulse Response (FIR) filters. A variety of frequency
domain digital filters are available including Fourier Transform (FT), Hilbert
Transform, and Kalman. Support is included for matrix-handling operations. A
variety of specialist filters, such as Cochleogram generation in both image and
matrix format from an audio buffer, are available.
“A variety of frequency domain digital
filters are available.”
“The SHIMMER platform comprises
SHIMMER Platform
a baseboard that provides the
The SHIMMER wireless sensor platform was developed by the Intel Digital
Health Group over a number of years to support a variety of internal research
projects. The SHIMMER platform comprises a baseboard that provides the
sensors computational, data storage, communications, and daughterboardconnection capabilities. The core functionality of SHIMMER platform is
extended via a range of daughterboards that provide kinematic, physiological,
and ambient sensing capabilities. This range of contact and non-sensing
capabilities can be reliably used both in clinical and in home-based scenarios.
sensors computational, data storage,
communications, and daughterboardconnection capabilities.”
SHIMMER Baseboard Design
“The primary advantages of the
MCU are its extremely low power
during periods of inactivity and its
proven history for medical-sensing
applications.”
The core element of the baseboard is the Texas Instruments MSP430* MCU
(Microcontroller Unit) [49], which has been widely used in wireless sensors
[50-52]. The primary advantages of the MCU are its extremely low power
during periods of inactivity and its proven history for medical-sensing
applications. The 10Kb of RAM on the MSP430F1611 variant is the largest
memory available within the processor family and offers improved buffering
capability for communication applications.
The MSP430 has eight ADC channels for 12-bit A/D conversions. For the
SHIMMER platform, the external ports are utilized for reading data from the
XYZ accelerometer (three channels), the internal expansion connector (three
channels), and the external expansion connector (two channels). To maintain
the low-power usage capabilities of SHIMMER, the MSP430 ADC core
is disabled when not in use and re-enabled when necessary. The baseboard
has a Freescale Semiconductor 3-axis (XYZ) accelerometer (MMA7260Q*).
The accelerometer is suitable for low-power systems: when active the current
consumption is around 500μA, and it contains a sleep mode, with current
usage of 3μA. It is robust, having high shock survivability, and is suitable for
high-sensitivity applications (800mV/g for 1.5g setting).
A passive tilt/vibration sensor (SQ-SEN-200* – Signal Quest) has been added
to later generations of the SHIMMER baseboard. It is sensitive to both tilt
(static acceleration) and vibration (dynamic acceleration). The sensor is used
to trigger power state transitions. For example, when the user takes an inactive
sleeping sensor out of the charging dock, the firmware will automatically switch
on the necessary components (accelerometer, radio, etc.) to begin capturing
and transmitting motion data.
Communications
“For the SHIMMER platform, the
external ports are utilised for reading
data from the XYZ accelerometer, the
internal expansion connector, and the
external expansion connector.”
One of the key functions of the SHIMMER board is its ability to communicate
as a wireless platform. SHIMMER has the dual functionality of having both
802.15.4 and Bluetooth® radio modules.
802.15.4 Radio
For IEEE 802.15.4-compliant wireless communication, the SHIMMER
platform uses a Chipcon CC2420* radio transceiver and a gigaAnt 2.4GHz
Rufa* antenna.
Bluetooth® Radio Module
The SHIMMER platform uses the Roving Networks RN-41* Class 2
Bluetooth module to communicate via an integrated 2.4GHz antenna. This
module contains a full Version 2 Bluetooth Protocol Stack and supports
the Serial Port Profile that facilitates rapid application development. The
Bluetooth module is connected to the MSP430 directly via the USART1 serial
connection. It can also be controlled by ASCII strings over the Bluetooth RF
link.
SHIMMER Daughterboards
For further functionality the SHIMMER baseboard has a Hirose Electric
DF12 series* connector that allows the user to connect daughterboards to the
baseboard. Currently there are seven daughterboards available for SHIMMER
as shown in Table 1.
Kinematic Sensing
Physiological Sensing
Ambient Sensing
Gyroscope
ECG
PIR Motion
Magnetometer
GSR
Temperature
Light
Table 1: BioMOBIUS SHIMMER-based sensors
Source: Intel Corporation 2009
External Connections
The external expansion (HIROSETM ST Series*) allows the user to attach the
board to the programming dock or multicharger.
External Hardware Integration
The SHIMMER platform provides two options for external hardware
integration, such as third-party sensors. The General Purpose Expansion
Module (AnEx Board) is an analog expansion module that enables two analog
signals to be plugged into the SHIMMER platform. These analog signals
interface with the A0 and A7 of the MSP430.
“The purpose of the PRIMMER
daughterboard is to enable rapid
integration and prototyping of
commercially available and existing
physiological front-end and sensor
circuitry.”
PRIMMER™ Daughterboard
Prototype Reconfigurable board for SHIMMER (PRIMMER) is a
daughterboard that enables the breakout of SHIMMER’s internal connector.
The purpose of the PRIMMER daughterboard is to enable rapid integration
and prototyping of commercially available and existing physiological front-end
and sensor circuitry. The PRIMMER daughterboard breaks out six ADC lines,
power and ground prototype solder points, two general purpose input/ouput
(GPIO) lines, and a Universal Asynchronous Receiver/Transmitter (UART).
In addition to this, it provides a boosted power supply by way of a powerboosting circuit that takes in 3V from the SHIMMER baseboard and increases
it to ±5V (Maxim MAX768EEE* charge pump). The board has been utilized
to interface to an EMG pre-amplifier sensor (MA-411-000*, Motion Lab
Systems) and to streamed EMG data at 500HZ.
“The GLIMMER display platform
is an extension of the standard
SHIMMER platform.”
GLIMMER™
GLIMMER, the SHIMMER-based display, is a low-cost, wireless display
platform that enables context-aware prompting in the home for ADL
monitoring, medication adherence, journaling, social messaging, and coaching
applications. The GLIMMER display platform is an extension of the standard
SHIMMER platform. Prompts are displayed via a 128x64x4bit 2.7” organic
light-emitting diode (OLED) display (OSRAM Pictiva™). The resolution is
128x64 with 4-bit grey for image display.
SHIMMER Peripherals
A number of peripheral components have been developed for the SHIMMER
platform, and among these are the following:
•• Programming dock. USB-bus-powered cradle using the FTDI FT232*
UART. The dock also has a battery charger status, USB Power, and UART
activity indicators.
•• Multicharger. Cradle that can charge six SHIMMERs simultaneously.
“SHIMMER firmware is primarily
developed by using TinyOS and
released into the public domain via
SourceForge.”
•• Advanced Dual UART programming board. For applications where wired
serial communication or enhanced debug capabilities are desirable.
•• Enclosures. The SHIMMER platform has two types of plastic enclosure. The
standard housing holds the SHIMMER baseboard, lithium ion battery, and
kinematic or ambient sensor daughterboards if required. The physiological
enclosure is utilized with the ECG and GSR daughterboards and provides
external connection points for electrodes.
SHIMMER Firmware
Firmware provides the low-level capabilities within the SHIMMER platform
to control the device functions. There are a number of lightweight operating
systems that can be used to run on a sensor node, namely TinyOS [53],
Contiki [54], Nano-RK [55], ERIKA [56], MANTIS [57], and SOS [58]. All
SHIMMER firmware is primarily developed by using TinyOS and released
into the public domain via SourceForge [59]. Firmware running on the sensor
platform provides local processing of the sensed data, local storage of the data
if required, and communications of these data to a higher-level application for
advanced signal processing, display and data persistence.
TinyOS handles task scheduling, radio communication, time, I/O processing,
etc. and has a very small footprint size. TinyOS is a lightweight, event-driven
operating system designed for sensor network nodes that have very limited
resources.
“TinyOS is a lightweight, eventdriven operating system designed for
sensor network nodes that have very
limited resources.”
Real-time Data Streaming to BioMOBIUS
SHIMMER data can be reliably streamed at rates up to 500HZ in real-time to
a BioMOBIUS application via the Bluetooth or 802.15.4 radios. To enhance
the reliable communications in addition to standard Bluetooth link reliability,
a packet format that supports various types of sensor data and provides
enhanced reliability to the data transmission through packet sequence numbers
and a cyclic redundancy check, was developed. The SHIMMMER firmware
(implemented in TinyOS version 1) uses the frame format shown in Figure 5
for BioMOBIUS application integration.
Packet
Framing
Packet
Header
Packet
Payload
“SHIMMER data can be reliably
streamed at rates up to 500HZ
in real-time to a BioMOBIUS
application via the Bluetooth or
802.15.4 radios.”
Packet
Framing
BOF
Sensor
ID
Data
Type
Frame
Sequence
Number
Time
Stamp
Data
Length
Raw
Sensor
Data
CRC
EOF
8 bits
8 bits
8 bits
8 bits
16 bits
8 bits
1-255 bytes
16 bits
8 bits
Figure 5: SHIMMER frame format
The content of packets is unrestricted binary data. This can lead to problems
with control characters like BOF (Beginning of Frame, hex byte ‘0xC0’) or
EOF (End of Frame, hex byte ‘0xC1’) appearing in the packet header or
payload and being interpreted as control characters. To avoid this issue, a byte
stuffing technique based on ISO’s asynchronous high-level data link control
(HDLC) protocol is utilized.
Logging Data to MicroSD Card
Many biomedical applications require subjects to have complete and
unhindered mobility. To achieve this, capability support for Secure Digital
(SD) card logging has been developed. The SHIMMER platform utilizes
a MicroSD card slot that supports up to two GBytes of flash memory. For
ambulatory ECG monitoring at 500 Hz from three channels, more than 80
days of data can be stored in uncompressed format. There are a number of
firmware programs available on SourceForge that facilitate recording of data to
the SHIMMER platform’s MicroSD card.
“The SHIMMER platform utilizes a
MicroSD card slot that supports up to
two GBytes of flash memory.”
“The goal is to minimize the on-time
of all hardware subsystems on the
sensor hardware platform.”
Power Management
A significant difference between most sensor nodes and standard computing
platforms is the heavy focus on power management and consumption. A
large number of applications require battery-powered operation for extended
periods of time [60]. Computational capabilities have far outstripped battery
technologies. SHIMMER battery optimizations have been implemented to
satisfy various project requirements. These optimizations implemented in
firmware have been mostly, but not exclusively, focused on lowering the duty
cycle of the 802.15.4 radio. The goal is to minimize the on-time of all hardware
subsystems on the sensor hardware platform. For example, each gyroscope on
the SHIMMER gyroscope daughterboard requires a supply current of 9.5mA.
With two dual-axis gyroscopes on the board there is a substantial 19mA
requirement that can be saved when the gyroscopes are off. Other auxiliary
battery features have been implemented for integration purposes, such as a low
battery indication sent by the SHIMMER platform to a BioMOBIUS software
application that prevents corrupted data from the accelerometer being received.
The accelerometer outputs are ratio metric which means the output offset and
sensitivity will scale linearly with applied supply voltage. Therefore, useful data
can only be generated if the supply voltage remains constant. The low battery
indication is a SHIMMER firmware feature that halts sampling of data when
the supply voltage falls below +3V.
Programming/Flashing SHIMMER
An intuitive mechanism to support the download of firmware executable
programs to SHIMMER sensors was highlighted as an important capability
for biomedical researchers. The SHIMMER development kit includes an
easy-to-use graphical application called the “SHIMMER Windows Bootstrap
Loader” to allow users who do not have a TinyOS installation on their system
to program SHIMMER sensors for their application needs.
SHIMMER Sensing Validation
The operation of the SHIMMER baseboard and daughterboards has been
tested through a number of validation processes to determine the accuracy
of the boards’ function and their usefulness for biomedical-oriented research
applications.
Electrocardiography (ECG) Validation
“A number of tests were carried out
to validate the SHIMMER ECG
daughterboard as a valid tool for
acquiring ambulatory ECG.”
A number of tests were carried out to validate the SHIMMER ECG
daughterboard as a valid tool for acquiring ambulatory ECG. The tests
consisted of validating the ECG amplifier and ADC performance by using
calibrated input signals and a resting ECG from a healthy subject in normal
sinus rhythm. Simulated ECG signals as well as an ECG recording from a
healthy non-resting subject were used to validate the performance SHIMMER
ECG daughterboard for use in ambulatory monitoring. Figures 6 and 7 show
a 1mV QRS amplitude (60 BPM) waveform generated by the Fluke MPS450
Patient Simulator* captured by a SHIMMER ECG and a MAC 3500 ECG
Analysis System* (GE Medical Systems). The plotted waveform (Figure 6) was
recognizable by a clinician as Normal Sinus Rhythm. Figure 7 shows the MAC
3500 ECG Analysis ECG System waveforms for comparative signal quality
purposes. Visual examination of the waveforms indicate that they compare
well.
Lead I
1
mVolts
0.5
0
-0.5
-1
3
4
5
6
Seconds
7
8
9
7
8
9
7
8
9
Lead II
1
mVolts
0.5
0
-0.5
-1
3
4
5
6
Seconds
Lead III
1
mVolts
0.5
0
-0.5
-1
3
4
5
6
Seconds
Figure 6: Simulated ECG signal of 1mV QRS amplitude captured by the
SHIMMER ECG
Figure 7: Simulated ECG signal of 1mV QRS amplitude captured by a MAC
3500 ECG Analysis System
“A 5.9 minute ECG recording
containing 503 heart beats from a
non-resting healthy subject during a
moderate walk was captured by the
SHIMMER ECG and also captured
by a Medilog Holter monitoring
system.”
QRS Detection of Normal Sinus Rhythm for a Non-resting Healthy
Subject
A 5.9 minute ECG recording containing 503 heart beats from a non-resting
healthy subject during a moderate walk was captured by the SHIMMER ECG
and also captured by a Medilog Holter monitoring system. The R-R intervals
and instantaneous heart rate (HR) identified by using the Medilog Holter ECG
monitor software were compared against the R-R intervals calculated by using
previously reported QRS detection and R-R interval correction algorithms
[61, 62]. Each automatically detected QRS point on the SHIMMER ECG
was manually verified to ensure correct detection by using the QRS detection
algorithm.
The mean R-R interval for the SHIMMER acquired ECG was 0.7049
seconds, while the mean R-R interval for the Medilog acquired ECG was also
0.7049 seconds. The percentage difference between the R-R intervals for each
acquisition was calculated on a beat-beat basis. The mean percentage error
between the R-R intervals calculated, by using each acquisition, was found to
be 0.0192 percent which can be considered negligible. These results indicate
that the SHIMMER ECG can be used to acquire ambulatory ECG from
resting and non-resting human subjects for research application purposes.
Kinematic Validation
In order to validate the SHIMMER platform for use in studies of human gait
analysis, temporal gait parameters derived from a tri-axial gyroscope on the
SHIMMER platform were compared against those acquired simultaneously, by
using the codamotion* analysis system from Charnwood Dynamics Ltd., UK.
The gait of one normal healthy adult male (age 25) was measured
simultaneously by using two SHIMMER sensors placed on each shank and the
Cartesian Optoelectronic Dynamic Anthropometer (CODA) motion analysis
system. Data were recorded whilst the subject performed multiple over-ground
walking and running trials along a 15-meter walkway in a motion analysis
laboratory. In all, ten walking trials at a self selected comfortable walking pace
and four running trials at a self-selected jogging pace were completed. Heel
strike and toe-off points were calculated from the medio-lateral angular velocity
derived from the gyroscope signal by using an algorithm reported by Salarian et
al. [63] as shown in Figure 8.
“Data were recorded whilst the subject
performed multiple over-ground
walking and running trials along
a 15-meter walkway in a motion
The heel strike and toe-off characteristic points derived from the SHIMMER
and CODA systems were used to calculate the three temporal gait parameters
listed below:
•• Stride time
•• Stance time
•• Swing time
analysis laboratory.”
150
Angular Velocity
Angular Velocity
th 2
100
All Peaks
Mid-Swing
50
0
-50
0
5
10
15
20
Time [s]
150
Angular Velocity
Angular Velocity
th 4
100
th 5
50
Heel Strike
Toe Off
0
-50
0
5
10
15
20
Time [s]
Figure 8: Shank angular velocity signal derived from the SHIMMER
gyroscope
Results show an intraclass correlation coefficient (ICC(2,k)) [64] greater than
0.85 in stride, swing, and stance times for ten walking trials and four running
trials. These results suggest that the SHIMMER platform is a versatile costeffective tool for use in temporal gait analysis. Full results from this study are
reported elsewhere [65]. Previous studies [66, 67] have validated the CODA
system as a reliable platform for gait measurements, so these results are very
promising.
“These results suggest that the
SHIMMER platform is a versatile
cost-effective tool for use in temporal
gait analysis.”
GSR Validation
The SHIMMER galvanic skin response (GSR) sensor contains an internal
resistor network that works as a potential divider and provides a voltage that
can be converted by the SHIMMER’s ADC to a 12-bit value, used to measure
external skin resistance. All skin resistance values were calculated in the
SHIMMER platform firmware and transmitted to a BioMOBIUS patch for
real-time display and persistence to file. The sensor performance was correlated
with a commercial Nexus-10* system (Mind Media BV) utilizing a series of
known resistors from 10KΩ to 2.2MΩ. SHIMMER GSR demonstrated an
average mean percentage error of 2.3 percent versus the commercial Nexus-10
that had an average mean error of 4.1 percent.
BioMOBIUS Prototype Applications
BioMOBIUS software has been utilized by the TRIL Centre for a number
of prototype applications both in clinical and home environments. A typical
BioMOBIUS-type application comprising the software and SHIMMER
wireless sensors described in this article is shown in Figure 9.
Application Development
Graphical User Interface
Embedded Signal
Processing
Sensor
Platform
Low Power Radios
Streaming Data
Over Radio
Data Analytics
Low Power Radios
for signals broadcasted
from Kinematic Data
sensors on
arms and legs
Physiological Data ECG
and Kinematic Data
Data Storage
Figure 9: Typical BioMOBIUS application
We now look at three TRIL Centre projects that have utilized the BioMOBIUS
research platform.
Gait Analysis Platform
The BioMOBIUS platform has been used to develop a prototype gait analysis
platform for use in a clinical environment and designed for early detection of
gait and postural instability. The system is designed to unobtrusively capture
gait parameters and physiological data. The platform comprises a number of
integrated subsystems that provide a true six degrees of freedom analysis, linked
to footfall data and visual gait data. Body-worn kinematic and sensor data are
provided by SHIMMER sensors and via a Tactex pressure-sensitive floormat.
Video data of the subject are provided via two Webcams. The hardware
components are integrated into a BioMOBIUS high-level application that
provides real-time visual feedback to clinicians. The system’s user interface
allows clinicians to select and adjust which data are collected and how the data
are processed. The software encapsulates data acquisition and signal processing
modules, and it allows customization of the sensors [68]. The system is being
used in the TRIL Clinic in St James’ Hospital, Dublin, Ireland to evaluate
scientifically the impact in non-normal gait changes and associated falls’ risks.
“The system’s user interface allows
clinicians to select and adjust which
data are collected and how the data
are processed.”
The MuSensor Project
The Tril Centre’s MuSensor project aimed to develop a cheap, unobtrusive,
home-based wireless sensor network to monitor an elder’s gait velocity
and doorway dwelling times over an eight-week period. The network
was developed using BioMOBIUS software and SHIMMER’s low-power
802.15.4 communications module and Passive Infrared (PIR) motion sensor
daughterboards. Each activation of a PIR sensor was time-stamped and
temporarily stored in the SHIMMER’s RAM, and batches of PIR events
were periodically uploaded via the 802.15.4 radio to a central data aggregator
located in the home. Data were then transferred to a server via a 3G GSM
network. The PIR sensor activation events were used to measure in-home
velocity of fallers and non fallers to determine if non performing (i.e., measured
outside a clinical environment) gait velocity of fallers and non fallers differs in
the home.
Engineering Alertness
This project is focused on the development of, and validation of, a prototype
BioMOBIUS application that can detect and correct lapses in alertness. The
study tests the viability of a self-alert training (SAT) protocol supported by
a BioMOBIUS software application with SHIMMER electrodermal activity
(EDA) sensors for measuring exosomatic EDA.
A small DC current was passed across two electrodes placed on the skin, and
the change in the resistance of the skin to the current was recorded as a
function of increased sweat gland activity (Figure 10). For DC measurements,
the current is kept constant and skin resistance is measured as changes in
voltage.
The protocol implemented in the application is designed to assist older people
in increasing attention and alertness levels in their own homes.
Developing the Ecosystem
BioMOBIUS software components can be downloaded for free from the
BioMOBIUS website (www.biomobius.org) under license from the TRIL
Centre. The website features a comprehensive set of documentation to support
both application and block developers. A variety of tutorials and sample
applications to assist new users are available. A user forum is also available
where users can log questions for TRIL engineers. A number of international
workshops have also been delivered to help with knowledge transfer in the
research community.
Figure 10. SHIMMER sensor measuring
electrodermal activity (EDA)
“BioMOBIUS software remains under
active development.”
The SHIMMER wireless sensor platform was licensed by Intel to Realtime
Technologies in 2007. SHIMMER development kits are now commercially
available from SHIMMER Research [42].
Conclusions and Future Work
BioMOBIUS software remains under active development. Version 2.0 of the
platform was released in late summer 2009. It features improved stability,
support for the X10* family of sensors, improved graphing capabilities in the
GUI Developer, support for SQLite* and MySQL* databases, improvements to
SHIMMER blocks, etc.
A number of new features are currently in development, including ODBC
support, Continua-compliant device support (www.continuaalliance.org) and
Web services data transports. New features and improvements will be available
to download from the BioMOBIUS website.
“Hardware components, such as the
SHIMMER wireless sensors platform
can be purchased from third-party
vendors.”
The BioMOBIUS research platform represents a set of highly integrated
software and hardware components developed by the TRIL Centre for
prototype biomedical research applications. The software components are
freely available for download to researchers. Hardware components, such
as the SHIMMER wireless sensors platform can be purchased from thirdparty vendors. The platform is open and extensible, allowing users to develop
new blocks for the graphical development environment or to integrate new
hardware components into the platform. The TRIL Centre has demonstrated
the use of the BioMOBIUS platform in a number of research projects
including the development of prototype gait analysis platform and EDA
monitoring applications. We believe that the BioMOBIUS research platform
will prove to be a useful and versatile tool in enabling the biomedical research
community. The prototype applications we developed with the BioMOBIUS
research platform and described in this article are for research purposes only
and are not commercially available.
Acknowledgements
We acknowledge the contributions of Barry Greene, Adrian Burns, Cliodhna
Ní Scanaill, and the Digital Health Group Product Research and Incubation in
the preparation of this article. We also recognize the TRIL Centre’s researchers
and their research programs, some of which are reported in this article.
“We believe that the BioMOBIUS
research platform will prove to be a
useful and versatile tool in enabling
the biomedical research community.”
References
[1]
R. Hongliang, M. Q. H. Meng, and C. Xijun. “Physiological
Information Acquisition through Wireless Biomedical Sensor
Networks.” In IEEE International Conference on Information Acquisition,
Hong Kong and Macau, China, 2005, pp. 483-488.
[2]
X. Chen, M. Q. H. Meng, and H. Ren. “Design of Sensor Node
Platform for Wireless Biomedical Sensor Networks.” In Proceedings
27th IEEE International Conference of Engineering in Medicine and
Biology Society, Shanghai, China, 2005, pp. 4662-4665.
[3]
G. S. Gupta, S. C. Mukhopadhyay, B. S. Devlin, and S. Demidenko.
“Design of a Low-Cost Physiological Parameter Measurement and
Monitoring Device.” In IEEE Conference on Instrumentation and
Measurement Technology, Warsaw, Poland, 2007, pp. 1-6.
[4]
A. Lymberis. “Smart Wearables for Remote Health Monitoring, from
Prevention to Rehabilitation: Current R&D, Future Challenges.” In 4th
International IEEE Engineering in Medicine and Biology Society Special
Topic Conference on Information Technology Applications in Biomedicine,
Birmingham, UK, 2003, pp. 272-275.
[5]
J. Kaye, T. Hayes, T. Zitzelberger, J. Yeargers, M. Pavel, H. Jimison, N.
Larimer, J. Payne-Murphy, E. Earl, K. Wild, L. Boise, D. Williams, J.
Lundell, and E. Dishman. “Deploying Wide-Scale in-home assessment
technology.” Technology and Aging: Selected papers from the 2007
International Conference on Technology and Aging, Toronto, Canada,
2007, pp. 19-26.
[6]
E. M. Tapia, S. S. Intille, and K. Larson. “Activity Recognition in the
Home Using Simple and Ubiquitous Sensors.” Pervasive Computing, vol.
3001, Berlin/Heidelberg: Springer, 2004, pp. 158-175.
[7]
R. Jafari, W. Li, R. Bajcsy, S. Glaser, and S. Sastry. “Physical Activity
Monitoring for Assisted Living at Home.” In 4th International
Workshop on Wearable and Implantable Body Sensor Networks,
Aachen, Germany, 2007, pp. 213-219.
[8]
T. Degen, H. Jaeckel, M. Rufer, and S. Wyss. “SPEEDY:a Fall Detector
in a Wrist Watch.” In Proceedings 7th IEEE International Symposium on
Wearable Computers, White Plains, New York, 2003, pp. 184-187.
[9]
J. Kaye. “Home-Based Technologies: A New Paradigm for Conducting
Dementia Prevention Trials.” Alzheimers and Dementia, vol. 4, no. 1, pp.
S60-S66, 2008.
[10] M. Morris, J. Lundell, and E. Dishman, “Catalyzing Social Interaction
with Ubiquitous Computing: a Needs Assessment of Elders Coping
with Cognitive Decline.” In Conference on Human Factors in Computing
Systems, Vienna, Austria, 2004, pp. 1511-1514.
[11] P. Bagnall, G. Dewsbury, V. Onditi, and I. Sommerville. “Promoting
Virtual Social Interaction with Older People.” In International Workshop
on Cognitive Prostheses and Assisted Communication, Sydney, Australia,
2006.
[12] D. G. Mcilwraith, J. Pansiot, S. Thiemjarus, B. P. L. Lo, and G. Z.
Yang. “Probabilistic Decision Level Fusion for Real-time Correlation
of Ambient and Wearable Sensors.” In 5th International Summer School
and Symposium on Medical Devices and Biosensors, Hong Kong, China,
2008, pp. 117-120.
[13] L. Atallah, M. ElHelw, J. Pansiot, D. Stoyanov, L. Wang, B. Lo, and G.
Z. Yang. “Behaviour Profiling with Ambient and Wearable Sensing.”
In 4th International Workshop on Wearable and Implantable Body Sensor
Networks, Aachen, Germany, 2007, pp. 133-138.
[14] C. Otto, Aleksandar Milenkovic, Corey Sanders, and E. Jovanov.
“System Architecture of a Wireless Body Area Sensor Network for
Ubiquitous Health Monitoring.” Journal of Mobile Multimedia, vol. 1,
no. 4, pp. 307-326, 2006.
[15] T. Westeyn, P. Presti, and T. Starner. “ActionGSR: A Combination
Galvanic Skin Response-Accelerometer for Physiological Measurements
in Active Environments.” In 10th IEEE International Symposium on
Wearable Computers, Montreux, Switzerland, 2006, pp. 129-130.
[16] D. Roetenberg, P. J. Slycke, and P. H. Veltink. “Ambulatory Position
and Orientation Tracking Fusing Magnetic and Inertial Sensing.” In
IEEE Transactions on Biomedical Engineering, vol. 54, no. 5, pp. 883890, 2007.
[17] S. Bamberg, A. Y. Benbasat, D. M. Scarborough, D. E. Krebs, and J.
A. Paradiso. “Gait Analysis using a Shoe-Integrated Wireless Sensor
System.” In IEEE Transactions on Information Technology in Biomedicine,
vol. 12, no. 4, pp. 413-423, 2008.
[18] S. J. Bellis, K. Delaney, B. O’Flynn, J. Barton, K. M. Razeeb, and
C. O’Mathuna. “Development of Field Programmable Modular
Wireless Sensor Network Nodes for Ambient Systems.” In Computer
Communications, vol. 28, no. 13, pp. 1531-1544, 2005.
[19] L. Benini, E. Farella, and C. Guiducci. “Wireless Sensor Networks:
Enabling Technology for Ambient Intelligence.” Microelectronics Journal,
vol. 37, no. 12, pp. 1639-1649, 2006.
[20] W.-Y. Chung and S.-J. Oh. “Remote Monitoring System with Wireless
Sensors module for Room Environment.” Sensors and Actuators B:
Chemical, vol. 113, no. 1, pp. 64-70, 2006.
[21] H. Dubois-Ferriere, R. Meier, L. Fabre, and P. Metrailler. “TinyNode:
a Comprehensive Platform for Wireless Sensor Network Applications.”
In Proceedings 5th International Conference on Information Processing in
Sensor Networks, Nashville, Tennessee, 2006, pp. 358-365.
[22] T. Ahola, P. Korpinen, J. Rakkola, T. Ramo, J. Salminen, and J.
Savolainen. “Wearable FPGA based Wireless Sensor Platform.” In
Proceedings 29th IEEE International Conference of Engineering in
Medicine and Biology Society, 2007, pp. 2288-2291.
[23] B. Gyselinckx, C. Van Hoof, J. Ryckaert, R. F. Yazicioglu, P. Fiorini,
and V. Leonov. “Human++: Autonomous Wireless Sensors for Body
Area Networks.” In Proceedings IEEE Conference on Custom Integrated
Circuits, San Jose, California, 2005, pp. 13-19.
[24] J. Penders, B. Gyselinckx, R. Vullers, M. De Nil, V. Nimmala, J. van de
Molengraft, F. Yazicioglu, T. Torfs, V. Leonov, P. Merken, and C. Van
Hoof. “Human++: From Technology to Emerging Health Monitoring
Concepts” In 5th International Summer School and Symposium on
Medical Devices and Biosensors, Hong Kong, China, 2008, pp. 94-98.
[25] L. Girod, N. Ramanathan, J. Elson, T. Stathopoulos, M. Lukac,
and D. Estrin. “Emstar: A Software Environment for Developing
and Deploying Heterogeneous Sensor-Actuator Networks.” In ACM
Transactions on Sensor Networks, vol. 3, no. 3, p. 13, 2007.
[26] S. Hengstler and H. Aghajan. “WiSNAP: A Wireless Image Sensor
Network Application Platform.” In 2nd International Conference on
Testbeds and Research Infrastructures for the Development of Networks and
Communities, Barcelona, Spain, 2006, pp. 6-12.
[27] Z. Walker, M. Moh, and T.-S. Moh. “A Development Platform for
Wireless Sensor Networks with Biomedical Applications.” In 4th IEEE
Consumer Communications and Networking Conference, Las Vegas,
Nevada, 2007, pp. 768-772.
[28] D. Simon, C. Cifuentes, D. Cleal, J. Daniels, and D. White. “Java™
on the Bare Metal of Wireless Sensor Devices:.” In Proceedings 2nd
International Conference on Virtual Execution Environments, Ottawa,
Ontario, 2006, pp. 78-88.
[29] R. Slyper and J. Hodgins, “Action Capture with Accelerometers.” In
ACM SIGGRAPH/Eurographics Symposium on Computer Animation,
Dublin, Ireland, 2008, pp. 193-200.
[30] D. Spelmezan, A. Schanowski, and J. Borchers. “Rapid Prototyping
for Wearable Computing.” In International Semantic Web Conference,
Karlsruhe, Germany, 2008.
[31] Y. Jianchu and S. Warren, “Design of a Plug-and-Play Pulse Oximeter.”
In Proceedings Second Joint IEEE 24th Annual Conference on Engineering
in Medicine and Biology and the Annual Fall Meeting of the Biomedical
Engineering Society Conference, Houston, Texas, 2002, pp. 1752-1753.
[32] M. Lascu and D. Lascu. “LabVIEW Electrocardiogram Event and Beat
Detection.” WSEAS Transactions on Computer Research, vol. 3, no. 1, pp.
9-18, 2008.
[33] T. Paing, J. Morroni, A. Dolgov, J. Shin, J. Brannan, R. Zane, and Z.
Popovic. “Wirelessly-Powered Wireless Sensor Platform.” In European
Conference on Wireless Technologies, Munich, Germany, 2007, pp. 241244.
[34] S. Scapellato, F. Cavallo, C. Martelloni, and A. M. Sabatini. “In-Use
Calibration of Body-Mounted Gyroscopes for Applications in Gait
Analysis.” Sensors and Actuators A: Physical, vol. 123-124, no. pp. 418422, 2005.
[35] S. Campbell, J.-P. Chancelier, and R. Nikoukhah. Modeling and
Simulation in Scilab/Scicos, 1st ed. New York: Springer, 2006.
[36] PROATECH BioEra—Visual Designer for BioFeedback webpage.
Available at http://www.bioera.net/
[37] C. Veigl and J. Wikerson. “BrainBay—an OpenSource Biosignal
Project.” Available at brainbay.lo-res.org/
[38] S. A. Jawed, D. CattIn, M. Gottardi, N. Massari, R. Oboe, and A.
Baschirotto. “A Low-Power Interface for the Readout and MotionControl of a MEMS Capacitive Sensor.” In 10th IEEE International
Workshop on Advanced Motion Control, Trento, Italy, 2008, pp. 122-125.
[39] J. Music, R. Kamnik, and M. Munih. “Model Based Inertial Sensing
of Human Body Motion Kinematics in Sit-to-Stand movement.”
Simulation Modelling Practice and Theory, vol. 16, no. 8, pp. 933-944,
2008.
[40] TRIL Centre, Technology Research for Independent Living webpage
(2009). Available at www.trilcentre.org
[41] SHIMMER wireless sensor platform webpage (2009, January). Available
at http://www.csi.ucd.ie
[42] Sensing Health with Intelligence, Modularity, Mobility and
Experimental Reusability webpage (2009). Available at
www.shimmer‑research.com
[43] A. Camurri, P. Coletta, M. Demurtas, M. Peri, A. Ricci, R. Sagoleo,
M. Simonetti, G. Varni, and G. Volpe, “A Platform for Real-Time
Multimodal Processing.” In 4th Conference in Sounds and Music
Computing, Lefkada, Greece, 2007, pp. 354-358.
[44] A. Camurri, P. Coletta, G. Varni, and S. Ghisio, “Developing
Multimodal Interactive Systems with EyesWeb XMI.” In Conference on
New Interfaces for Musical Expression, New York, 2007, pp. 305-308.
[45] A. Camurri, B. MazzarIno, M. Ricchetti, R. Timmers, and G. Volpe,
“Multimodal Analysis of Expressive Gesture in Music and Dance
Performances.” Gesture-based Communication in Human-Computer
Interaction, vol. 2915, A. Camurri and G. Volpe, Eds. Berlin/
Heidelberg: Springer Verlag, 2004, pp. 357-358.
[46] A. Camurri, B. MazzarIno, G. Volpe, P. Morasso, F. Priano, and C. Re.
“Application of Multimedia Techniques in the Physical Rehabilitation
of Parkinson’s Patients.” Visualization and Computer Animation, vol. 14,
no. 5, pp. 269-278, 2003.
[47] M. L. Rinman, A. Friberg, B. Benediksen, D. Cirotteau, S. Dahl, I.
Kjellmo, B. MazzarIno, and A. Camurri, “Ghost in the Cave—An
Interactive Collaborative Game Using Non-verbal Communication.”
Gesture-based Communication in Human-Computer Interaction, vol.
2915, A. Camurri and G. Volpe, Eds. Berlin/Heidelberg: Springer
Verlag, 2004, pp. 403-404.
[48] Raw Material Software—JUCE webpage (2005). Available at
www.rawmaterialsoftware.com/juce/
[49] MSP430 16-bit Ultra-Low Power MCUs webpage (2009). Available at
focus.ti.com/
[50] B. Lo, S. Thiemjarus, R. King, and G. Z. Yang. “Body Sensor
Network—A Wireless Sensor Platform for Pervasive Healthcare
Monitoring.” In 3rd International Conference on Pervasive Computing,
Munich, Germany, 2005, pp. 77-80.
[51] J. Polastre, R. Szewczyk, and D. Culler. “Telos: Enabling UltraLow Power Wireless Research.” In 4th International Symposium on
Information Processing in Sensor Networks, Los Angeles, CA, 2005, pp.
364-369.
[52] G. Werner-Allen, K. Lorincz, M. Ruiz, O. Marcillo, J. Johnson, J. Lees,
and M. Welsh. “Deploying a Wireless Sensor Network on an Active
Volcano.” IEEE Internet Computing, vol. 10, no. 2, pp. 18-25, 2006.
[53] TinyOS Community Forum webpage (2009 June). Available at
http://www.tinyos.net
[54] A. Dunkels, B. Gronvall, and T. Voigt. “Contiki — A Lightweight and
Flexible Operating System for Tiny Networked Sensors.” In 29th Annual
IEEE International Conference on Local Computer Networks, Tampa,
Florida, 2004, pp. 455-462.
[55] A. Eswaran, A. Rowe, and R. Rajkumar. “Nano-RK: An EnergyAware Resource-Centric RTOS for Sensor Networks.” In 26th IEEE
International Real-Time Systems Symposium, Miami, Florida, 2005, pp.
5-8.
[56] M. Cirinei, A. Mancina, D. Cantini, P. Gai, and L. Palopoli. “An
Educational Open Source Real-Time Kernel for Small Embedded
control systems.” Computer and Information Sciences - ISCIS 2004, vol.
3280, BerlIn/Heidelberg: Springer, 2004, pp. 866-875.
[57] S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C.
Gruenwald, A. Torgerson, and R. Han. “MANTIS OS: an embedded
multithreaded operating system for wireless micro sensor platforms.”
Mobile Network Applications, vol. 10, no. 4, pp. 563-579, 2005.
[58] V. Tsetsos, G. Alyfantis, T. Hasiotis, O. Sekkas, and S.
Hadjiefthymiades. “Commercial Wireless Sensor Networks: Technical
and Business Issues.” In 2nd Annual Conference on Wireless On-demand
Network Systems and Services, St Moritz, Switzerland, 2005, pp. 166173.
[59] SourceForge webpage (2009, June). Available at http://sourceforge.net
[60] J. Hill, M. Horton, R. Kling, and L. Krishnamurthy. “The Platforms
Enabling Wireless Sensor Networks.” Communications of the ACM, vol.
47, no. 6, pp. 41-46, 2004.
[61] D. Benitez, P. A. Gaydecki, A. Zaidi, and A. P. Fitzpatrick. “The Use of
the Hilbert Transform In ECG Signal Analysis.” Computers in Biology
and Medicine, vol. 31, no. 5, pp. 399-406, 2001.
[62] P. de Chazal, C. Heneghan, E. Sheridan, R. Reilly, P. Nolan, and M.
O’Malley. “Automated Processing of the Single-Lead Electrocardiogram
for the Detection of Obstructive Sleep Apnoea.” IEEE Transactions on
Biomedical Engineering, vol. 50, no. 6, pp. 686-696, 2003.
[63] A. Salarian, H. Russmann, F. J. G. Vingerhoets, C. Dehollain, Y. Blanc,
P. R. Burkhard, and K. Aminian. “Gait Assessment In Parkinson’s
Disease: Toward an Ambulatory System for Long-Term Monitoring.”
IEEE Transactions on Biomedical Engineering, vol. 51, no. 8, pp. 14341443, 2004.
[64] P. E. Shrout and J. L. Fleiss. “Intraclass Correlations: Uses In Assessing
Rater Reliability.” Psychological Bullet, vol. 86, no. 2, pp. 420-428, 1979.
[65] K. J. O’Donovan, B. R. Greene, D. McGrath, R. O’Neill, A. Burns, and
B. Caulfield. “SHIMMER: A New Tool for Temporal Gait Analysis.”
In Proceedings 31st IEEE Engineering in Medicine Biology Conference,
Minneapolis, MN, 2009.
[66] K. Monaghan, E. Delahunt, and B. Caulfield, “Increasing the Number
of Gait Trial Recordings Maximises Intra-Rater Reliability of the
CODA Motion Analysis System.” Gait & Posture, vol. 25, no. 2, pp.
303-315, 2007.
[67] V. Maynard, A. M. O. Bakheit, J. Oldham, and J. Freeman. “IntraRater and Inter-Rater Reliability of Gait Measurements with CODA
MPX30 Motion Analysis System.” Gait & Posture, vol. 17, no. 1, pp.
59-67, 2003.
[68] K. O’Donovan, T. Dishongh, T. Foran, D. Leahy, and C. Ni Scanaill.
“The Development of a Clinical Gait Analysis System.” In Conference on
Ambulatory Monitoring of Physical Activity and Movement, Amsterdam,
Netherlands, 2008, p. 155.
Author Biographies
Michael McGrath is Senior Technologist in Intel’s Digital Health Group. He
is also a co-Principal Investigator in the TRIL Centre focusing on development
technologies to support independent living research. Michael McGrath joined
Intel in 1999. He has held positions as an automation engineer working in
Ireland Fab Operations and as a researcher in IT Research and Innovation.
He moved to his current position as a technologist in the Product Research
and Incubation group in 2006. His areas of interest include sensors, wireless
communications, assisted living technologies, intelligent user interfaces,
data fusion, and data management techniques. Michael received his B.Sc. in
Analytical Science from Dublin City University in 1992 and a Ph.D. in sensors
and instrumentation from Dublin City University in 1995. His e-mail is
michael.j.mcgrath at intel.com.
Terrance (Terry) J. Dishongh, Ph.D., is currently a Senior Principal Engineer
in Intel’s Digital Health Group. In his twelve years at Intel he has been awarded
45 patents with an additional 44 pending and has published books on wireless
sensors and electronic packaging. Dr. Dishongh has held faculty positions at
the University of Maryland, College Park and the State University of New York
at Buffalo. His e-mail is terry.dishongh at intel.com.
Copyright
countries.
Gathering the Evidence: Supporting Large-Scale Research
Deployments
Contributors
Tamara L. Hayes
OHSU & ORCATECH
Misha Pavel
OHSU & ORCATECH
Jeffrey A. Kaye
OHSU & ORCATECH
Abstract
Independent living technologies have tremendous potential to facilitate the
study of aging and chronic disease. By collecting medical and behavioral data
continuously as people live their daily lives, we are able to form a much clearer
picture of the changes in people’s health, and the efficacy of treatments over
time, than is possible by using periodic clinical visits. However, deploying these
technologies in large-scale clinical trials poses unique challenges. In this article
we review those areas in which independent living technologies can provide
significantly improved research data, and the challenges that must be overcome
to effectively gather those data. We propose approaches, both technical and
procedural, which enable efficient management of large-scale research studies,
and we discuss scalability issues and their possible solutions.
Introduction
Index Words
Aging
Home Monitoring
Clinical Research
Scalability
“Over 20 percent of people 85 and
older have a limited capacity for
independent living.”
People aged 65 and older are the fastest growing segment of the United States
population: it is predicted that this number will more than double by the year
2030. Forty-two percent of this age group reported some type of long-lasting
condition or disability [6]. Furthermore, over 20 percent of people 85 and
older have a limited capacity for independent living [5], requiring continuous
monitoring and daily care. Almost 6 percent of private health expenditures
and approximately 13 percent of all public healthcare expenditures in 2005
were spent on home healthcare and nursing-home care for older adults [4]. The
convergence of growing numbers of seniors with attendant chronic illness, the
rising costs and complexity of care, and the inability to effectively develop and
apply increasing knowledge of how to treat or manage these health declines
merge to create a well-recognized crisis of healthcare in America.
A major challenge to research into caring for the aged is the reliable assessment
of behavior and clinical status across multiple related domains (for example,
cognitive, social, physiological, environmental). Clinical research has not
fundamentally changed its tools of conduct and assessment paradigm since the
beginning of the computer age. Thus, clinical research is currently still rooted
largely in traditional clinical practice methodologies, where the basic paradigm
of assessment is a clinical interview or examination, relying on the recall of
the volunteer, performed at a brief moment in time, at a location convenient
for the researcher, not the volunteer. Even when technologies are deployed in
the home, they are often used in a brief or episodic way (for example, 24-hour
heart monitoring or two weeks of actigraphy) and not fully integrated into the
clinical data stream and workflow.
148 | Gathering the Evidence: Supporting Large-Scale Research Deployments
There have been several research efforts that have developed solutions for
monitoring and assessment of individuals in their homes. These approaches use
unobtrusive wireless sensors placed in a subject’s home (such as motion sensors,
door sensors, and environmental sensors), or technologies that the subject
wears or uses (such as medication adherence monitors, telemedicine boxes,
personal computers, and body-worn location and activity sensors). Studies that
use these technologies have found that even simple technologies can be
valuable in assessing behavior in the home [13], and there are a growing
number of researchers developing and evaluating emerging technologies for
in-home assessment and health intervention. These technologies have the
potential to transform the clinical research landscape by enabling the
simultaneous assessment of an individual’s activity, function, and physiologic
status in a particular location across a wide array of time scales (for example,
seconds to seasons), and by creating the potential to detect subtle changes in
that status, by comparing this rich multidimensional data stream with baseline
data from prior observations.
The general approach to this kind of study is to monitor a subject (or patient)
over a period of time to establish a baseline, after which deviation from that
baseline can be used to detect clinically-relevant change. Without this baseline,
patients must instead be compared to a population norm–and what is normal
for one individual may be a cause for alarm in someone else. Furthermore,
by sampling infrequently, true trends may be masked, as a person has good
days and bad days. Figure 1 illustrates how infrequent sampling can lead
to substantial aliasing errors. In the figure, you will see that the top panel
depicts test scores taken during a standard clinic visit, taken at six-month
intervals, for two different patients. Then note that the bottom panel depicts
how continuous assessment could reveal a very different picture. Thus, the
continuous nature of the in-home sensor data collection allows many data
points to be collected, providing better time resolution for looking at changes
and for reducing the overall variance. This continuous collection also allows
changes to be detected in a shorter period of time. The immediacy and
frequency of the collection of these data form the basis for the transition to
a true substantiation of personalized medicine and directly aligns with new
healthcare delivery trends and mandates, including the wide-scale build-out
of electronic medical or health records [19], the Medical Home [8], and
comparative-effectiveness research (CER) [14].
Measured Function
Month 1
Month 6
Month 12
Figure 1: Problems with Infrequent Monitoring
Source: Alzheimer’s and Dementia: Hayes TL,
Abendroth F, Adami, A, Pavel, M, Zitzelberger TA,
Kaye JA
The Role for In-Home Monitoring in Research
In-home monitoring has wide applicability in routine care and intervention. In
particular, in-home monitoring allows tracking of conditions that evolve slowly
over time or that have poor demarcation of onset; and it allows the tracking
of conditions that transition to new clinical states, such as depression, frailty,
and cognitive impairment. Suitable sensors placed in the home may also allow
immediate detection of acute events that are rare or irregularly occurring, such
as falls, naps, or transient neurological events.
“In-home monitoring has wide
applicability in routine care and
intervention.”
Gathering the Evidence: Supporting Large-Scale Research Deployments | 149
“In many cases in aging research, the
variance in a measure may be more
informative than the absolute value.”
“The metrics of interest would become
true rates of change and not simply
binary ‘present or absent’ estimates.”
Continuous monitoring would also greatly enhance clinical trials of both
drug and behavioral therapies, by allowing the ongoing assessment of patient
adherence to the trial or therapy regimen, and by providing those administering
these trials the ability to assess side-effects and health changes throughout the
day. Traditionally, both adherence and side-effects in clinical trials are measured
through self-report, which at best corresponds modestly to actual medication
taking and to true physiological changes [17, 20] (see Vignette 1 at the end
of this article). The immediate identification of side-effects accurately aligned
to the time of treatment would provide valuable insights into the efficacy of
treatments. Data about patient behaviors would allow improved coaching of
the patient to ensure better adherence to the treatment protocol. Furthermore,
in studies of recovery (such as from a hip fracture or stroke), instead of
assessing outcomes by using subjective measures, for example, arbitrary scale
numbers at a fixed time point such as 3-6 months after the event, new measures
could be generated from recovery curves that represent the rate of functional
recovery (such as total activity or walking speed). One of the most interesting
benefits of using the continuous home assessment platform is not only the
opportunity to examine the trends in these objective measures, but equally
importantly, to determine their variability over time. In many cases in aging
research, the variance in a measure may be more informative than the absolute
value [12, 16].
The ability to improve on self-report also has the potential to transform
epidemiological studies. Currently, epidemiological survey and assessment
methodologies tend to rely on sparsely spaced questionnaires that depend on
recall of events. This approach makes it difficult to identify data or events with
detailed temporal or spatial precision, and it limits their ecological validity.
A way to improve this state is to bring the locus of assessment into the home
or community by providing a means of recording continuously, in real-time,
events as they occur and where they occur. If full sensor networks and on-line
reporting capabilities were incorporated into thousands of households, there
would be an opportunity to collect changing health outcomes at the point
of occurrence. In this case the metrics of interest would become true rates of
change and not simply binary “present or absent” estimates. Item-level data
would be much less reliant on recall (e.g., “In the last six months how often
did you wake at night?”) and instead reflect actual events and more objective
measures (e.g., the number of bathroom visits, hours in bed, and so on).
Achieving Large-Scale Studies
Recent advances in ubiquitous computing and sensor network methodologies
make large-scale, in-home research studies feasible. When coupled with
other convergent technologies and methods, such as ecological momentary
assessment and telemedicine, the potential to transform the practice of clinical
research is staggering. However, in spite of the number of smart homes that are
now being used to develop and evaluate in-home monitoring technologies,
we are a long way from wide-scale deployment. Experience has shown that
solutions that appear to work in a controlled laboratory environment, even
when that environment is intended to simulate a home living situation, never
work as expected in the field. For this reason, we have developed a staged
approach to designing solutions for large-scale, in-home monitoring.
Assess Attitudes and Beliefs
SU RV EY
Evaluate in Point-of-Care Lab
Internet
Test in Community Living Lab
Internet
Deploy on a Large Scale
Internet
Internet
Internet
Internet
Internet
Figure 2: Scaling In-home Assessments from the Lab to Communities
Source: OHSU
Figure 2 illustrates the stages we use from technology inception to wide-scale
deployment. First, we conduct focus groups and interviews to inform the
technology design, and in particular to understand attitudes towards the
technology and to identify key usability and acceptance issues. In the second
stage, technologies are tested in a smart-home environment (the Point of Care
Laboratory) by using convenience samples of participants. Data collection can
be done quickly and easily, under controlled experimental conditions, and
therefore this approach is appropriate for initial evaluations of technologies.
However, these tests will not typically allow the collection of outcome measures
that are representative of particular patient populations. Therefore, part of this
“We conduct focus groups and
interviews to inform the technology
design.”
“Subjects brought into a smart home
will not behave as they would in their
own home.”
“The Living Lab is a group of senior
volunteers who have agreed to allow
technologies to be evaluated in their
homes on an ongoing basis.”
“The high, inter-individual variability
stage includes bringing patients or subjects from the target cohort into the
smart home, to collect additional data about how the population of interest
will interact with the sensor systems. This is useful for improving our
understanding of the limitations and capabilities of the sensor technologies.
Clearly, subjects brought into a smart home will not behave as they would in
their own home, and therefore data collected in such an environment has less
ecological validity than those collected in the individual’s home. Hence, the
third stage entails taking the technology into the field — that is, instrumenting
a small number (10-20) of patients’ homes — to provide much better
outcomes’ data. We use the ORCATECH Living Lab for this deployment. The
Living Lab is a group of senior volunteers who have agreed to allow
technologies to be evaluated in their homes on an ongoing basis. A core set of
technologies is continually maintained in the homes, and clinical and
neurological assessments are conducted on this cohort on a semi-annual basis.
This deployment helps to reveal problems that may arise when the technology
is used with different home construction materials, infrastructure support,
living arrangements, or patient populations. Once a technology has been
field-hardened in the Living Lab, we are ready to begin to scale it to larger
studies.
In spite of the challenges of scaling emerging technologies, there is a clear need
to do so. The high inter-individual variability in behavior and health outcomes
drives the need for large studies. For example, while small randomized
clinical trials of cholinesterase inhibitors have shown modest improvements
in cognitive function, trials with treatment and control groups of 200 – 300
people are typically necessary to have sufficient power to show improvements
from baseline [18]. Population-based studies require a much larger sample size,
since these studies typically control less for co-morbidities, and therefore the
variance in those samples is much greater.
In the process of deploying various in-home monitoring and intervention
technologies in more than 400 homes around the United States, we have
learned a great deal about the challenges of scaling the technologies for
research. These challenges relate in part to the complex, heterogeneous nature
of the data that are collected, in part to the challenges of adding the use of
technology into the already difficult problem of recruiting and retaining patient
populations (who may be technophobic), and in part to the fact that the global
infrastructure and sensors designed specifically for collecting behavioral health
data do not yet exist. In the remainder of this article we review each of these
challenges and propose possible solutions.
in behavior and health outcomes
drives the need for large studies.”
The Nature of the Data
Continuous, in-home monitoring studies generate a vast amount of data
pertaining to the daily activity of subjects. These datasets may contain mixtures
of complex data, ranging from rare and random events to continuous signals.
Uniquely, these data inherently describe multiple data domains simultaneously:
space or location, time, activity, physiological function, neuropsychological
function, etc. These data provide more accurate and detailed information
than can be captured by traditional methods of self-report, and they hold
information about patterns of activity in the home that could be used to
examine a multitude of hypotheses about behaviors, such as restlessness at
night, nocturia, patterns of use of the kitchen (and refrigerator), outings from
the home, and acute events such as falls or stroke. However, the very strengths
of these data — such as the high sampling frequency and the many different
types of information gathered — make them challenging to manage, study,
monitor, and interpret.
There are three key types of data that are needed to support large-scale research
studies. The first type of data that is of interest is the raw data from the
sensors themselves. These data reflect physical responses of the sensors to the
behaviors of the research participants. For example, the instantaneous signal
strength from a body-worn radio frequency identification (RFID) sensor as
an individual walks through the home, the time at which a motion sensor
fires when somebody passes by, and the force measured by a load cell under
the support of a bed as a person breathes, are all signals that must be captured
for subsequent processing and inference. Some of these (signal strength, load
cell force) are sampled at regular intervals and form a time series sampled at a
relatively high frequency. Others (sensor firing time) are event-driven, and the
amount of data collected therefore depends upon the activity being sensed.
Furthermore, these data may also be tied to location, and therefore they may
require a spatio-temporal representation.
“These datasets may contain mixtures
of complex data, ranging from rare
and random events to continuous
signals.”
“These data may also be tied
to location, and therefore they
may require a spatio-temporal
representation.”
The second type of data is metadata about the sensors, the state of the sensors,
and participants themselves. If one is relying on signal strength to estimate
location, for example, then the battery level of the sensor becomes important
to determining the likely variance and accuracy of the estimate. Similarly, if a
motion sensor appears to have stopped firing, it is important to know if there is
a hardware or communications problem or if the person being monitored has
simply not passed near the sensor.
The third type of data is derived data, which come from inference algorithms
that are used to extract information from the raw data. Often these derived
data actually arise from sophisticated statistical models that fuse data from
multiple sensors to make inferences about behaviors and health outcomes.
Derived data could be as basic as an estimate of respiration or walking speed,
or as complex as a determination of how well a person was performing a
particular activity of daily living (ADL). The derivation of such measures and
metrics from in-home sensors is an area of active research, and at this point,
only a small number of measures have been developed and validated.
“The derivation of such measures
and metrics from in-home sensors
is an area of active research, and at
this point, only a small number of
measures have been developed and
validated.”
“As purposed sensors become more
common, what was once derived data
will become raw data.”
The applicability of each of these types of data typically relates to the maturity
of the sensor technology. For example, a pulsed ultra-wideband location sensor
could provide data in the form of the time-difference-of-arrival measures, or
could provide an estimate of the individual’s location, based on a sophisticated
algorithm that integrates data from multiple nodes. If the sensor were welltested and its behavior in home environments was well-understood, then
the expense of storing the raw data might not be warranted. Instead, the
location estimates would be sufficient. Thus, as purposed sensors become more
common, what was once derived data will become raw data, which in turn will
be used to develop more sophisticated and complex measures.
Managing Large-Scale Studies
“Unlike standard clinical trials,
in‑home studies require central
tracking and remote systems
management capabilities.”
“Short installation time and high
equipment reliability become essential
in a large study.”
Conducting a large-scale, in-home trial differs from conducting a small pilot
study as well as from conducting standard clinical trials. First, in large studies,
the recruitment of subjects is often done across multiple sites in different cities
or states, which raises issues of staff training, forming relationships with local
infrastructure providers at each location, dealing with regional differences in
attitudes towards the technologies, and cross-site coordination. Furthermore,
unlike standard clinical trials, in-home studies require central tracking and
remote systems management capabilities. Second, the innumerable possible
variations on home configurations and environmental conditions means that
in-home technology must be adaptable to many environments, which is not
always straightforward. Third, short installation time and high equipment
reliability become essential in a large study. Fourth, because in-home
technologies can potentially produce a large amount of raw data, centralized
data management and a means of visualizing and reviewing the data are
essential as well.
In our studies, the data and the remote installations are managed by using
the ORCATECH Management Console (OMC), a multi-tiered remote
monitoring application built from Open Source tools. This software tool
was designed to support the activities of both clinical and technical research
assistants. OMC provides a central view into the data and has the following
capabilities:
•• View subject and home information (floor plans, sensor placements,
demographic info, etc.).
•• Track recruitment and subject status, including generating alerts for
upcoming scheduled visits for assessments or equipment installation.
•• Track contact with subjects, for assessing total cost of installations (for
example, time and frequency of support phone calls and visits).
•• Roll up the health of the installed systems (and raise alerts if sensors fail to
fire, or data fails to transfer).
•• Provide summary views of the data to enable data validation on an ongoing
basis. Figure 3 shows an example in which computer use is displayed for the
two residents in a home. In this graph, we also plot in-home activity, since
we should not expect any computer use if nobody is home.
Alerts
Data Outage
Equipment
X10
MedTracker Events
Start Date:
Graphs
Personal
Residents
End Date:
Ekahau
2009-07-31
Computer Usage
Submit
Home Activity
12
11
10
9
8
7
6
Logins
X10 Events
Pets
21,000
20,000
19,000
18,000
17,000
16,000
15,000
14,000
13,000
12,000
11,000
10,000
9,000
8,000
7,000
6,000
5,000
4,000
3,000
2,000
2009-07-01
Phone Monitor Events
5
4
3
2
1
2009-07-05
2009-07-12
2009-07-19
2009-07-26
Date
X10 Events
(738)
(760)
Figure 3: Checking Data Integrity with the ORCATECH Management
Console
Source: OHSU
In the following sections we discuss the core issues this study management tool
was designed to support — and those issues that still need to be addressed to
make this tool ultimately scalable to studies that include thousands of subjects.
Cohort Management
One of the greatest challenges for any large-scale study is the recruitment and
retention of the participant cohort. The challenges are exacerbated when the
participant population is asked to use or interact with unfamiliar technology.
In aging studies, many participants have never used a computer or cell phone
and are highly intimidated by the thought of learning to do so. In one of our
longitudinal studies, we require the participants to use a personal computer
on a weekly basis. Approximately 32 percent of the participants we recruited
already owned their own computer. The majority of the remainder, 169
subjects, were provided with a computer and trained to use it. A significant
effort was spent in developing a training program that included skills ranging
from the use of the mouse and how to double-click, to sending and receiving
e-mail (a definition of computer literacy). The training program comprised
six hour-long lessons that were taught to small groups. Clearly, this is not an
approach that scales to tens of thousands of subjects. However, many computer
classes for seniors are now available through libraries and senior centers, and
through partnerships with such programs, it is possible that large-scale studies
requiring frequent computer use may be viable even in studies of older adults,
such as our studies (where the mean age is over 80 years old).
“A significant effort was spent in
developing a training program that
included skills ranging from the use
of the mouse and how to double-click,
to sending and receiving e-mail (a
definition of computer literacy).”
“For an individual with a tremor,
pressing a single key on a cell phone or
moving a mouse to a target on a screen
may be literally impossible to do with
accuracy.”
Many of the technologies available commercially, such as cell phones and mice,
are difficult to use for older adults. For an individual with a tremor, pressing
a single key on a cell phone or moving a mouse to a target on a screen may
be literally impossible to do with accuracy. For many elderly, the text on a
cell phone is too small to see, even with glasses. Recent research has provided
considerable insight into the usability needs of the aging population [2, 3, 15,
21], and large-scale studies must be prepared to adapt their technologies to
accommodate the wide variety of needs in this population.
This difficulty with the technology translates into a retention problem for
research studies: participants that become frustrated are more likely to drop
out of the study. Therefore, in technology-based studies, even more than in
traditional clinical studies, it is vital to maintain active personal relationships
with the participants. In our own studies, this is done by maintaining
continuity of contact as much as possible. Each participant has an assigned
research assistant that they know well and with whom they are used to
interacting. In addition, we maintain a help-line for the participants to call
with any questions they may have about the technology. By knowing that they
will receive a response about their problem within a day, and that somebody
wants to help them through it, the participants are able to give voice to their
frustrations, which is often all that is needed to defuse the situation. Of course,
not all participants are frustrated by the technology.
“It is vital to maintain active personal
relationships with the participants.”
“In aging studies, transitions are part
In aging studies, transitions are part of life. Many participants will move to
smaller homes, to assisted living, or they will move in with family over the
course of a study. Even more participants will become ill, have an exacerbation
of a chronic disease, or undergo surgery. In a study of behaviors or health
outcomes, these transitions will have a significant impact on the data. It is
important to track these changes, and in some cases to collect additional
data that will help in the interpretation of changes in the data that result
from the life transition. For example, in our Intelligent Systems for Assessing
Aging Changes (ISAAC) project, we are interested in changes in walking
speed over time. In this project, 6.8 percent of our participants have moved
in the last eight months. Often, their new homes are smaller, and therefore
the participants do not need to move around as much to go from room to
room. Alternatively (or in addition), the participants may have made the
change because of changing health needs that themselves impact their daily
activity. Therefore, in order to understand how the home move impacts our
measurements of activity, it is important to study the time periods around
these transitions carefully, and to understand what health changes may have
happened at the same time. To help us understand these data, we ask our
participants to complete weekly online questionnaires about any health
changes, medication changes, or emergency room visits that may have occurred
in the previous week.
of life.”
One final area of cohort management is important to consider. Many
technology-based studies place expensive equipment into the homes of the
participants. Depending on the neighborhood, this technology can make
the participant a target for break-in and theft. Furthermore, in studies with
cognitively impaired subjects, quite a few of the subjects will forget what the
technology is for or even that it is in their home. In these cases, participants
may pack up the equipment or even give it away. While these situations are
rare, their resolution takes time and money.
“Many technology-based studies place
expensive equipment into the homes of
the participants.”
Technology Management
There are three keys to successful technology management in a large-scale,
in‑home study: a stream-lined and well-supported installation process,
continuous remote tracking of system status, and the ability to do remote
management and maintenance of installed technologies. Our approach in each
of these areas has changed over the years, as we have partnered with study sites
around the country and have learned many lessons.
The installation of in-home technology often involves sensors and devices that
are unfamiliar to many study assistants. Even setting up a computer may be
outside the experience of the typical research assistant (RA). Therefore, the
technology installation must be both orderly and as idiot-proof as possible. In
addition, a live help line is essential to provide support for inexperienced RAs.
For example, in one study in which medication tracking devices and computer
kiosks for administering monthly or quarterly neuropsychological evaluations
were to be installed in 200 homes in 25 cities around the country, we created
a laminated step-by-step installation instruction sheet that was packed in the
box with each technology set. All connectors between the equipment were
color coded, and the instructions included photographs of how those colorcoded connectors should be connected. A set of pre-install steps were clearly
specified, including forming a working relationship with the local broadband
provider for billing and technical support prior to commencing installs. Study
coordinators from all sites converged locally for a one-day training session in
which we attempted to cover possible problems with the installation. In spite
of these preparations, the help line assistant received 55 calls during the first
57 installations. While the need for support tapered off sharply by the time
each site had installed two systems, about two-thirds of sites still called for
additional assistance at least once in the first year. Clearly, an effective help line
with well-trained staff is one of the most essential components of ensuring a
successful multi-site, large-scale, study deployment.
The continuous monitoring of equipment status is another important
component of ensuring good data collection in a large-scale study. In our
studies we do this through the ORCATECH Management Console, which
queries the status of numerous system variables in each home once per day.
Figure 4 shows an example in which an alert screen provides visual indicators
of the status of the sensors. The system checks for problem indicators daily and
displays them as a red bar. Technicians can then reclassify the problems when
they have determined the cause. Colors reflect the problem status. Multiple
days can be displayed to assist in tracking problem status over time.
“There are three keys to successful
technology management in a largescale, in-home study: a stream-lined
and well-supported installation
process, continuous remote tracking
of system status, and the ability to do
remote management and maintenance
of installed technologies.”
“The continuous monitoring of
equipment status is another important
component of ensuring good data
collection in a large-scale study.”
Alerts
Services
Summary
Pass:
Select Colored Cells to Classify
2009-08-04 (02:00:01)
Apartment
Classify
1020
Home Id
History:
1192
Alert:
16
1194
1196
Sensor PC
1198
Reload
1200
1203
1205
Print
1207
20
85
109P
94
204B
109
414S
112
127
317
150
212
160
301P
Unread
64
Unread
Watch
413
304B
1558RR
Oa
E 303
161
Not an Issue
Create New Issue
Out of Home
229
237
259
B 106
261
312
335
334
336
315
348
1012
401
Figure 4: Screenshot of the ORCATECH Management Console Alert Screen
Source: OHSU
A great deal of system problem triaging can be done programmatically.
Communication status between the routers and the in-home computers, the
status of services running on the sensor computers in the home, remaining
device battery life, failure to receive sensor heartbeats, sensor data values out
of expected range, and even failure of the participant to complete a weekly
form, can all be flagged as possible issues and brought to the attention of the
study staff. Serious problems, which may result in the loss of data, can then
be identified quickly and addressed immediately. By tracking the time taken
to triage and fix problems, we are able to assess the overall quality of the study
support.
“Scientifically, it is important to not
visit with the participants more than
necessary due to the study protocol.”
Finally, remote maintenance of installed technologies is an extremely important
component of conducting in-home trials, both scientifically and financially.
Scientifically, it is important to not visit with the participants more than
necessary due to the study protocol, because that contact may itself influence
the outcome of the study. For example, in one of our studies we are interested
in changes in walking speed and motor activity over time. Each time we visit
a participant’s home to repair activity sensors, they become aware of their
own activity and may subtly alter their behavior for a short period of time as
a result. Furthermore, frequent visits to the participants can be an irritant to
them, which puts study retention at risk. Financially, it is expensive to travel
to participants’ homes to make repairs. Clearly, some repairs require in-person
visits (replacing batteries or broken equipment), but many things can be fixed
remotely (restarting services, scheduling tasks, pushing new software versions,
helping participants with computer programs, etc.). Wake-on-LAN capability
has proven to be an extremely valuable feature of the in-home computer. In our
Figures 5 and 6 show the repair history for one of our studies, the ISAAC
project [9]. In this project participants have passive infrared sensors distributed
throughout their home to detect activity and walking speed and a personal
computer that we use to track inter-keystroke intervals (a surrogate for finger
tapping speed) and their interaction with a series of games. This study has two
technical RAs who are responsible for supporting the 248 participants and 190
homes in the study. In Figure 5, you can see the clear pattern of install/bug
fix that we engaged in during ramp-up of the study. Once the project reached
steady state, the number of fixes trended down, reflecting the fact that issues
that spanned multiple homes had been identified and addressed. At this point
in the project, most fixes are maintenance issues, such as battery changes and
issues with broadband.
200
Total number of
Installed homes
In-home fixes
Phone support
Remote fixes
Number of installs/fixes
180
160
140
120
100
80
60
40
20
“Once the project reached steady state,
the number of fixes trended down.”
0.13
Average number of fixes per month per home
studies, we used a laptop to collect sensor data that did not have wake-on-LAN
capability in its wireless LAN card. As a result, in those homes in which we
used 802.11g to connect to the router, we were unable to remotely boot many
of the sensor computers that went off-line.
In-home fixes
Phone support
Remote fixes
0.11
0.09
0.07
0.05
0
09
9
9
l–0
Ju
y–
Ma
09
08
08
8
8
08
r–0
Ma
n–
Ja
v–
No
p–
Se
l–0
Ju
y–
Ma
r–0
Ma
07
07
7
07
08
n–
Ja
v–
No
p–
Se
l–0
Ju
y–
Ma
0.03
Router
Sensors
Sensor PC
User PC
Figure 5: Patterns of Installation and Fixes on the ISAAC Project
Figure 6: Types of Fixes for Each of the Four
Source: OHSU
Major Technologies Installed in the ISAAC Project
Source: OHSU
Figure 6 shows the ratio of in-home visits to support calls with the participant,
to remote fixes, for the main problem areas. Because participants in this study
are required to use their computer weekly, we have put into place a help line
(e-mail and phone) that they can call for support. This is reflected in the large
number of remote fixes done on the PC, which often take the form of
undeleting a subject’s file that they cannot seem to locate, restoring e-mail
settings that they have changed by mistake, or deleting spy ware that was
inadvertently downloaded by their grandchildren. In spite of our best efforts to
provide FAQs, handouts, and in-person training on basic computer use issues,
many relatively simple tasks remain a challenge to the individuals who have
never used computers prior to our studies.
“Surprisingly, most computer problems
unrelated to participant use have
required on-site visits.”
Surprisingly, most computer problems unrelated to participant use have
required on-site visits. This is a major barrier to scalability at this time. In
part, this reflects the limited capabilities of the in-home systems used in this
study. We chose inexpensive laptop computers running Windows* XP* for
our study, in part because of the need to keep costs under control, and in part
because some of the commercial sensor software we were using runs only under
Windows. However, these laptops turned out to have unreliable network cards
as well as some obscure device driver issues. Furthermore, at the time the study
started, Intel® vPro™ technology was not yet available. Had we been able to
use such technology, we would have been able to remotely diagnose a number
of sensor computer issues rather than visit the home. Overall, our considered
opinion at this time is that a Linux*-based system would perform more reliably,
as well as require significantly less memory.
Data Management
“The data must be appropriately
anonymized to protect the subjects’
privacy, and they must be stored
securely.”
“While none of these issues are
unsolvable, some choices may be
irreversible.”
The management of the data from in-home technology studies raises some
unique issues. Of primary concern is the security of the data and the privacy
of the participants. At all levels of data management (acquisition, transmission
to a central site, ongoing storage, and retrieval for analysis), the data must
be protected. Many organizations, such as the Veteran’s Administration,
have highly-regulated restrictions on where the data may be stored, when
they need to be encrypted, and who may access them. However, even in
research organizations with fewer regulations, the data must be appropriately
anonymized to protect the subjects’ privacy, and they must be stored securely.
Data acquisition poses interesting challenges to maintaining this privacy, since
often the data are not encrypted before being sent to a local receiving device.
As described in the section on the Nature of the Data, raw data, metadata, and
derived data all have different properties. As a result, they also have different
storage needs. Large-scale, longitudinal studies that follow hundreds or
thousands of subjects over years need to consider options for data compression,
data storage, and data retrieval. As derived measures are developed, are the raw
data still needed? Is it appropriate to archive these data, or does it make more
sense to create a hierarchical storage model in which older data are downsampled or summarized over longer time periods? Do meta-data need to be
kept beyond the period in which they are used to address technology issues? If
they are discarded, what historical data should be kept to allow for evaluation
of the study’s efficiency? As derived measures evolve over time, how should
the versions be documented and stored? For large datasets, where processing
the data to derive the measures may take hours or days, it may make the most
sense to store all of the derived datasets. In other cases, where storage is at a
premium, it may make more sense to store the algorithms used to derive the
measures. While none of these issues are unsolvable, some choices may be
irreversible. As a result, it is important to have a clear data management policy
in place at the start of any large, in-home study.
Scalability Issues
There are many issues that need to be addressed if large-scale deployments of
in-home research studies are to be successful. One issue centers on the diversity
of technology experience and acceptance in the aging population. A second
issue is the lack of available tools for interpreting the complex data that result
from such studies, and the need to enable data-sharing through visualization
tools. However, the largest scalability issue is the lack of technology
infrastructure, specifically focused on supporting large-scale research studies.
We discuss these issues in more detail next.
“The largest scalability issue is the
lack of technology infrastructure,
specifically focused on supporting
large-scale research studies.”
Managing Diverse Populations
Differences in living environments, in attitudes towards technology, and
even in the relative extent of in-home versus out-of-home activity across
different groups may require modifications in the platform and approach for
continuous in-home assessment. For example, a recent ORCATECH study
[1] suggested that rural seniors may have several technological challenges.
Of 128 seniors aged 80 or older that were surveyed, only 5 percent reported
using a computer frequently, or sending or receiving e-mail daily. This cohort
is a good example of the kind of research and environmental challenges that
could be encountered during wider deployment in terms of subject training,
and in terms of collecting and transferring of data. Another group that may
provide unique challenges is low-socioeconomic status (SES) elderly. SES is a
combined measure of an individual’s economic and social position relative to
others. SES is often assessed based on a method proposed by Hollingshead,
which considers level of education and occupation. Krousel-Wood [11] found
that level of education adversely affected patients’ willingness to participate in
a telemedicine study. In addition, due to economic constraints, this cohort is
less likely to use a computer on a regular basis. Therefore, a particular challenge
in this group could be recruiting and training on computer use. Finally,
cognitively impaired elders are often less able to interact with technology.
The other interesting issue that arises when a study is scaled nationally is
regional differences in home construction. For example, in our national
studies using in-home technologies, we have found that the wiring in many
of the older homes in New York City result in high data loss with DSL
broadband. For commercial applications, such issues may mean loss of market
opportunity and disappointment in some populations that the technologies
do not work in their home. For a research study, such differences could result
in loss of access to a key demographic or cohort. For example, participants
with low socioeconomic status often live in older homes. This is a population
notoriously underserved by the research community because they are less likely
to volunteer for studies and must therefore be actively recruited. However,
these individuals may benefit greatly from aging-in-place technologies, and
therefore they are an important cohort for inclusion in research studies.
“Another group that may provide
unique challenges is low-socioeconomic
status (SES) elderly.”
“We have found that the wiring in
many of the older homes in New York
City result in high data loss with DSL
broadband.”
The Need for Visual Analytics
“In the field of unobtrusive in‑home
monitoring, there has been no
coordinated effort to share data from
past and ongoing studies.”
As mentioned previously, sensor-based, in-home studies generate large amounts
of complex data. It is well accepted that sharing research data increases
collaboration, increases research activity, and reduces the cost of research [10].
However, in the field of unobtrusive in-home monitoring, there has been no
coordinated effort to share data from past and ongoing studies. Even if the data
were available, analysis of those data requires significant domain knowledge and
an understanding of the sensors, their deployment, and the clinical and sensor
datasets that have been collected during the study. Therefore, there is a clear
need for extensible, modular tools that allow researchers to focus on the data,
without being mired in the details of the sensor technologies.
Specifically, new data analytic tools must be created. Data analytics is the use of
visualization and descriptive statistical techniques for initial data exploration.
Visualization is the display of multiple dimensions of a dataset graphically,
grouped by some feature or category of interest. Visualization is meant to
take advantage of the human capacity to process visual information quickly
and efficiently. In the case of complex data such as in-home monitoring
data, visualization tools must allow exploration of the spatial and temporal
properties of the sensor data, as well as fuse information from multiple sensor
types to examine interactions between different behavioral measures. These
tools will enable collaboration between researchers already focused on this
emerging paradigm, and they will facilitate entry into this area of research
by investigators who may lack the resources to undertake the necessary data
collection, the access to key patient populations, or both, thereby increasing the
opportunities for discovery and formation of new hypotheses.
“More than 50 percent of technology
issues were a result of failed
broadband.”
“We have been forced to repurpose
sensors developed for inventory
tracking and security applications.”
The Need for Global Technology Solutions
One of the primary barriers to wide-scale deployment of in-home, technologybased research studies is the lack of universally available and supported Internet
infrastructure. In the one multi-state study in which we have used in-home
technologies, more than 50 percent of technology issues were a result of
failed broadband, ranging from a poor signal due to old wiring in the home,
to difficulty on the part of the Internet service provider (ISP) in getting the
broadband up and working in the home, and to the ISP discontinuing service
inadvertently or because of billing errors on their part. There are no low-cost
broadband options available universally across the country, and multi-site
studies therefore require establishing a separate ISP relationship and billing
agreement with each city, and sometimes each county, where the study is to be
conducted. This is a significant administrative barrier to large-scale deployment
for research.
Another significant barrier to wide-scale, in-home research studies is the lack of
a platform supporting purposed sensors designed for gathering behavioral and
physiological data in the home. In our current studies, we have been forced to
repurpose sensors developed for inventory tracking and security applications for
our activity monitoring. In those cases where we have developed a new sensor
(for example, with medication tracking [7]), it was done with a particular
project in mind and did not grow out of a principled architecture intended
to support the growing needs for different types of sensors. Ultimately, what
is needed is the integration of sensors designed to optimize the collection of
specific behavioral and physiological data with a platform built on an open,
standards-based architecture. It is our hope that such an architecture may
ultimately be derived from the combined efforts of organizations such as
Continua Alliance, industry leaders promoting interoperable standards for
personal health; Integrating the Healthcare Enterprise (IHE), an initiative
sponsored by professional societies to provide a common framework for
multi-vendor system integration; and the International Organization for
Standardization (ISO), which has specified numerous standards for health
devices and is one of the sponsoring organizations of Health Level 7 (HL7).
The research community has an additional need: standards-based data sharing
and storage models, such as those developed by the Clinical Data Interchange
Standards Consortium (CDISC) that have been endorsed by the FDA for use
with clinical drug trial data. With the advent of large-scale, in-home studies
that use technology to aid in the assessment and detection of health and
behavior changes, there will be increasing amounts of temporal and spatial
sensor data, as well as health outcome data, to be gathered, stored, analyzed,
and archived for efficient later retrieval. Sharing of these research data would
allow investigators to develop new algorithms for deriving health status and
interpreting behavior from these data, without the considerable costs and
resources that would be incurred if each investigator had to collect his or her
own data. Data sharing is most effective when a standard data format and set of
tools are available to facilitate data sharing. Unfortunately, current, continuous
monitoring studies all use different methodologies, and thus far, none have
made their data widely available to the research community for further
analysis of health outcomes. No tools currently exist to facilitate the sharing of
continuous monitoring data. Thus, the development of a common architecture
for sharing and visualizing sensor-based study data is another key requirement
for true scalability.
“What is needed is the integration
of sensors designed to optimize the
collection of specific behavioral and
physiological data with a platform
built on an open, standards-based
architecture.”
“Data sharing is most effective when
a standard data format and set of
tools are available to facilitate data
sharing.”
Conclusions
There is tremendous hope that independent living technologies may lead to a
reduction in the cost of healthcare delivery in this country. These technologies
have the potential not only to support aging-in-place, but to enhance our
ability to assess and remediate health changes in the elderly. Although a
number of mid-sized research studies using such technologies are underway,
there are still significant barriers to their deployment in large-scale clinical
trials. However, we are beginning to understand these barriers and to find
solutions to overcoming them, which will lead some day soon to a significant
evolution in the practice of clinical research.
Vignette
“I never miss a pill.”
After taking care of herself for 23 years since her husband died, 85-yearold Ana is pretty sure she has things under control. Although she takes five
medications each day, three in the morning and two at night, she maintains
strict control of her medication regimen and is able to cheerfully confirm that
she has taken her meds when she talks to her daughter in their nightly phone
call. When she enrolled in our medication adherence study, we asked her to add
a low-dose vitamin C to her regimen once in the morning and once at night
when she took her regular meds. She put these into our Medtracker pillbox
and agreed to take them twice a day. Ana scored very well on her cognitive test,
achieving a score that was a little lower than some but still considered normal
for her age.
After a couple of days, we noticed that she had stopped taking the vitamins and
gave her a call to remind her to take them. She was adamant that she’d been
taking them when she took her own meds, and so we went out to her house to
replace the Medtracker, which clearly wasn’t working properly. However, when
we got there, we found that the pillbox was still full of pills. Ana was sure she
had taken them, and thought that somebody else must have put more pills into
her box. She wanted to continue in the study so we reviewed how to fill up the
pillbox each week. After five weeks in the study, Ana’s overall adherence was 38
percent. To this day she maintains that she “only missed a couple of pills.”
References
[1]
Calvert J., Kaye, J., Leahy, M., Hexem, K., and Carlson, N. 2009.
“Technology use by rural and urban oldest old.” Journal of Medicine and
Technology. In press.
[2]
Chadwick-Dias A., McNulty, M., and Tullis, T. 2003. “Web usability
and age: How design changes can improve performance.” In Proceedings
of the 2003 Conference on Universal Usability, Vancouver, B.C., Canada,
pp. 30-37.
[3]
Chadwick-Dias A., Tedesco, D., and Tullis, T. 2004. “Older adults and
web usability: Is web experience the same as web expertise?” In Aging by
Design Workshop, Bentley, MA.
[4]
Centers for Medicaid and Medicare Services. 2005. National Health
Expenditures: web tables. Available at www.cms.hhs.gov.
[5]
Erickson P., Wilson, R., and Shannon, I. 1995. Years of Healthy Life. US
Department of Health and Human services, CDC, National Center for
Health Statistics, Statistical Notes 7, Hyattsville, Maryland.
[6]
Gist Y. J. and Hetzel, L. I. 2004. We the people: Aging in the United States
(CENSR-19). Available at www.census.gov.
[7]
Hayes T. L., Hunt, J. M., Adami, A., and Kaye, J. 2006. “An electronic
pillbox for continuous monitoring of medication adherence.” In 28th
Annual International Conference of the IEEE Engineering in Medicine and
Biology Society, New York, NY.
[8]
Iglehart J. K. 2008. “No place like home—testing a new model of care
delivery.” New England Journal of Medicine, 359(12), 1200-2.
[9]
Kaye J. A., Hayes, T. L., Zitzelberger, T. A., Yeargers, J., Pavel, M.,
Jimison, H. B., Larimer, N., Payne-Murphy, J., Earl, E., Wild, K.,
Boise, L., Williams, D., Lundell, J., and Dishman, E. 2008. “Deploying
wide-scale in-home assessment technology.” In Technology and Aging,
vol. 21. In Assistive Technology Research Series. A. Mihailidis, J. Boger, H.
Kautz, and L. Normie, Eds.: IOS Press, pp. 19-26.
[10] Koslow S. H. 2005. “Discovery and integrative neuroscience.” In
Clinical EEG in Neuroscience. 36(2), pp. 55-63.
[11] Krousel-Wood M. A., Re, R. N., Abdoh, A., Chambers, R., Altobello,
C., Ginther, B., Bradford, D., and Kleit, A. 2001. “The effect of
education on patients’ willingness to participate in a telemedicine
study.” Journal of Telemedicine and Telecare, 7(5), pp. 281-7.
[12] Li S., Aggen, S. H., Nesselroade, J. R., and Baltes, P. B. 2001. “Shortterm fluctuations in elderly people’s sensorimotor functioning predict
text and spatial memory performance: The Macarthur Successful Aging
Studies.” Gerontology, 47(2), pp. 100-16.
[13] Logan B., Healey, J., Philipose, M., Tapia, E. M., and Intille, S. 2007.
“A long-term evaluation of sensing modalities for activity recognition.”
Vol. 4717. In Lecture Notes in Computer Science, Innsbruck, Austria:
Springer Verlag, pp. 483-500.
[14] Mitka M. 2009. “Studies comparing treatments ramp up.” Journal of the
American Medical Association, 301(19), 1975.
[15] Murata A., Nakamura, H., and Okada, Y. 2002. “Comparison of
efficiency in key entry among young, middle and elderly age groups—
effects of aging and character size of a keyboard on work efficiency in
an entry task.” In 2002 IEEE International Conference on Systems, Man
and Cybernetics, Oct. 6-9 2002, Yasmine Hammamet, Tunisia, 2, pp.
96-101.
[16] Salthouse T. A., Nesselroade, J. R., and Berish, D. E. 2006. “Short-term
variability in cognitive performance and the calibration of longitudinal
change.” Journal of Gerontology Series B: Psychological Sciences and Social
Sciences, 61(3), pp. 144-151.
[17] Stone A. A., Pennebaker, J. W., Keefe, F. J., and Barsky, A. J. 2000. “Part
VII: Self-Report of Physical Symptoms.” In The Science of Self-Report:
Implications for Research and Practice. A. A. Stone, Ed. Mahwah, NJ:
Lawrence Erlbaum Associates, pp. 297-362.
[18] Takeda A., Loveman, E., Clegg, A., Kirby, J., Picot, J., Payne, E., and
Green, C. 2006. “A systematic review of the clinical effectiveness of
Donepezil, Rivastigmine and Galantamine on cognition, quality of
life and adverse events in Alzheimer’s disease.” International Journal of
Geriatric Psychiatry, 21(1), pp. 17-28.
[19] Tang P. C. and Lee, T. H. 2009. “Your doctor’s office or the Internet?
Two paths to personal health records.” New England Journal of Medicine,
360(13), pp. 1276-8.
[20] Tourangeau R. 2000. “Remembering What Happened: Memory Errors
and Survey Reports.” In The Science of Self-report: Implications for
Research and Practice. A. A. Stone, Ed. Mahwah, NJ: Lawrence Erlbaum
Associates, pp. 29-48.
[21] Ziefle M. and Bay, S. 2005. “How older adults meet complexity: Aging
effects on the usability of different mobile phones.” Behaviour and
Information Technology, 24(5), pp. 375-389.
Acknowledgements
The research described in this article was funded through grants from the
National Institutes of Health (NIA grants P30AG024978 P30AG08017, and
R01AG024059), by Intel Corporation, and by the Kinetics Foundation.
Author Biographies
Tamara Hayes, PhD, is Assistant Professor and Associate Division Head of
Biomedical Engineering at Oregon Health and Science University (OHSU).
She received her MS degree in Electrical Engineering at the University of
Toronto and her PhD in Behavioral Neuroscience from the University of
Pittsburgh. She has worked in both industry and academia, on projects
ranging from creating tools for remote management of distributed systems to
delivering teledermatology care to rural Oregon. Dr. Hayes’ current research
interests include the use of technology to deliver healthcare in the home, with
the goal of changing the current paradigm of clinic-centered healthcare to a
model that is less costly, more effective, and allows individuals to participate
more fully in their own healthcare. This research entails the use of low-cost,
unobtrusive sensors in the home for collecting behavioral data related to acute
and chronic motor and cognitive changes, and meaningful analysis of these
data to assist and inform the patient.
Misha Pavel, PhD, is Division Head and Professor of Biomedical Engineering
at Oregon Health and Science University (OHSU). He is also Director of
the Point of Care Laboratory, which focuses on unobtrusive monitoring
and neurobehavioral assessment and modeling. He received his PhD in
Experimental Psychology from New York University and his MS degree in
Electrical Engineering from Stanford University. His research interests include
analysis and modeling of complex behaviors of biological systems, including
perceptual and cognitive information processing, pattern recognition,
information fusion, and decision making in healthy and cognitively impaired
individuals.
Jeffrey A. Kaye, M.D., is a Professor of Neurology and Biomedical
Engineering and the Director of the Layton Aging and Alzheimer’s Disease
Center, as well as Director of the Oregon Center for Aging and Technology
(ORCATECH) at Oregon Health and Sciences University. Dr. Kaye received
his medical degree from New York Medical College and trained in neurology
at Boston University. His Alzheimer’s research is focused on understanding
differing rates of progression and cognitive decline as compared to optimal
cognitive health in the elderly. Through his work with ORCATECH, he seeks
to facilitate successful aging and reduce the cost of healthcare through the use
of in-home technologies for assessment and remediation.
Copyright
countries.
Assistive Technology for Reading
Contributors
Selena Chan
Intel Corporation
Ben Foss
Intel Corporation
David Poisner
Intel Corporation
Index Words
Assistive Technology
Independent Living
Dyslexia
Visual Impairment
Blindness
Specific Learning Disability
Abstract
Over 82 million people in the developed world face challenges each day when
attempting to read a variety of printed materials. The challenges may be due
to blindness, partial vision loss, or reading-based learning disabilities, such as
dyslexia. Regardless of the cause, people of all ages suffer a huge loss in their
independence and productivity when they must rely on others to read material
on their behalf or struggle to read at a rate so slow that they become frustrated
and discouraged. This article focuses on the design and technical challenges of
addressing this user need and the more general complexities of designing an
independent-living product for a user group that ranges from teens to seniors
and from those who are conversant with technology to those who downright
fear it.
The Intel® Reader is the output of years of research into end-users who
experience difficulty reading text for a variety of reasons. The Intel Reader is
a mobile device that combines a high-resolution camera with an Intel Atom™
processor to take pictures of text and read that text aloud to the user on the
spot.
Designing the Intel Reader presented challenges in many areas: user interface,
mechanical and electrical, and usage flows and specification of the system-level
requirements. In this article, we first review the diverse end-user population
for this technology, and we identify unique subpopulation requirements that
were distilled into a set of common parameters. We explore many of the
design challenges, tradeoffs, and unexpected discoveries that led us to the final
definition for the Intel Reader.
Introduction
“For a large number of people, reading
printed text is a barrier.”
168 | Assistive Technology for Reading
Printed text is a default form of communication in the developed world.
Beginning in early elementary school, reading is a central component of
education and is the foundation for building independent, analytical skills. As
students grow and begin to enter the workforce, the ability to read memos,
purchase orders, and industry-related articles is critical to promotions and
successful performance reviews. As the working adult matures, the prevalence
of vision impairment increases and poses a challenge to those who desire to live
an independent lifestyle. And for a large number of people, reading printed
text is a barrier. This group of people includes those with specific learning
disabilities, those with partial vision loss, and those who are completely blind.
“The Intel Reader is a mobile device
that takes pictures of text, translates
the image into digital text by using
optical character recognition (OCR)
technology, and reads the text aloud by
using text-to-speech (TTS) software.”
Figure 1: The Intel Reader
The Intel Reader is a mobile device that takes pictures of text, translates
the image into digital text by using optical character recognition (OCR)
technology, and reads the text aloud by using text-to-speech (TTS) software.
Figure 1 shows a photograph of the Intel Reader, after many rounds of
prototype design iterations and user-focused group discussions. It is roughly
6.5” by 5.5” by 1.1”, about the size of a paperback book. The Intel Reader
contains a high-resolution camera, designed to capture crisp images of text.
To improve the accuracy of OCR, it is critical that the text images are of high
resolution and as sharp as possible. When designing the user interface for the
Reader, we took into account the findings from our ethnographic research
and we incorporated many human factors into our design to provide print
accessibility to the target audience: we included features such as image rotation
and automatic correction to increase the accuracy of the conversion. The Intel
Reader utilizes the Intel Atom processor and a Linux* operating system.
Disabilities and the Challenges of Reading
Reading can be challenging for a variety of reasons ranging from learning
disabilities to partial or complete blindness.
“We took into account the findings
from our ethnographic research and
we incorporated many human factors
into our design to provide print
accessibility to the target audience.”
Assistive Technology for Reading | 169
“Roughly 10 to 15 percent of any
given population has specific learning
disabilities, with 80 percent exhibiting
reading-based learning disabilities
consistent with dyslexia.”
“Reading becomes an uphill battle and
remains slow and laborious.”
Reading-Based Learning Disability
Reading can be a frustrating experience for people who have specific learning
disabilities. For example, dyslexia is a neurological disability, often characterized
by difficulties with word recognition, word spelling, and word decoding.
One participant in our research described reading as “having a bad cell phone
connection with the paper — words drop out or come through garbled even
though I can see just fine.” Dyslexia, like most learning disabilities, is an
inherited condition, and not the result of lack of effort, sensory impairment,
or of inadequate education. Roughly 10 to 15 percent of any given population
has specific learning disabilities, with 80 percent exhibiting reading-based
learning disabilities consistent with dyslexia. In the United States, there are
55 million people with specific learning disabilities in the public schools, 8
million of whom are students under the age of 18 who have dyslexia. Although
studies may vary, it is estimated that 30 – 45 million people are in this target
population overall in the United States alone.
The majority of students first learn to read by phonemic awareness (how
speech sounds make up words) and by connecting those sounds to letters
of the alphabet (phonics). Next, they learn to blend the sounds into words,
recognize words, and comprehend what they read. People with specific learning
disabilities, however, have difficulty with phonemic awareness and phonics.
Research has shown that dyslexia occurs because information is processed
differently in the brain, and for this reason, reading becomes an uphill battle
and remains slow and laborious. When students struggle with these early
stages of reading, they are often made to feel inferior. Frustration and isolation
resulting from this lack of independence can be intense, leading to high dropout rates and associated social problems.
With intensive and early help, students with dyslexia are often able to learn
the basic skills of reading and develop strategies that allow them to stay in
the conventional classroom. Generally, however, they are not able to achieve
a level of reading fluency commensurate with their level of intelligence and
aptitude. While they may be able to get words off a page with great effort, they
are generally at a great disadvantage, relative to the majority of their peers,
especially when it comes to comprehension. However, the comprehension of
spoken words is not affected by dyslexia, and as a result, audio processing of
information is highly desirable for individuals with dyslexia.
Blindness and Visual Impairments
“Anyone with non-correctable reduced
vision is considered to be visually
impaired.”
For people with vision-loss, reading poses a real challenge. Anyone with noncorrectable reduced vision is considered to be visually impaired. Cataracts,
glaucoma, macular degeneration, corneal opacity, diabetic retinopathy, and
trachoma are examples of pathologies that can cause vision acuity loss. Vision
impairment can range from severe low vision (uncorrectable beyond 20/200
to 20/400) to near total blindness (less than 20/1000). At the extreme end,
individuals who completely lack light perception are considered totally blind.
Visual impairment is unequally distributed across age groups. More than 82
percent of all people who are blind are over 50 years of age, although they
represent only 19 percent of the world’s population. There are an estimated
1.4 million blind children below age 15 in the world. In the next 30 years, an
ever-increasing number of people will develop some form of visual impairment
due to the aging of our population. Potentially blinding eye conditions, such as
age-related macular degeneration (AMD), diabetic retinopathy, and glaucoma
are increasing as the world’s population ages.
In recent years, as technology has become more prevalent, a number of assistive
tools have emerged for people with disabilities. There are text readers that help
students build reading comprehension skills, a number of computer programs
are available to help students with literacy, and audio books have emerged as an
alternative format to help students read by listening. Audio books are typically
available for common textbooks, selected novels, and popular magazines
and newspapers. Additionally, for content that is in electronic format, such
as websites and e-mails, text-to-speech software can be used to convert it to
audio. However, there are documents that exist primarily in printed format,
such as store receipts, coupons, business memos, personal mail, and specialty
publications, all of which require an alternative means of access. Alternative
access means reliance on a third party, be it a scanning service to get access to
text, or a special educator to provide on-going support. The Intel Reader was
developed to address these needs, offering an evolution of the existing assistive
technologies to a more portable and intuitive usage model, as well as access to
text at a time and place of the user’s choosing.
“Potentially blinding eye conditions,
such as age-related macular
degeneration (AMD), diabetic
retinopathy, and glaucoma are
increasing as the world’s population
ages.”
“The Intel Reader was developed
to address these needs, offering an
evolution of the existing assistive
technologies to a more portable and
intuitive usage model.”
End-User Personas
When we started developing the Intel Reader we talked with end users who
allowed us to gain insight into their needs, and who gave us the opportunity
to hear how they use current technology in their everyday lives. To obtain a
deeper understanding for end-user needs, we began with usage research. As
part of this phase, we interviewed targeted users, followed them through a day
in their lives, and observed their daily challenges at home and at work, and
asked for their insights on the challenges of daily living. Over the course of this
project, we have interviewed and tested the product at various stages with over
200 individuals.
“Over the course of this project, we
have interviewed and tested the
product at various stages with over
200 individuals.”
The process began by interviewing 20 end users from various target groups and
developing a broad set of model personas to guide our design choices along the
way. Initially, over 30 composite characters were generated, each representing
key elements of the user population. The key characteristics, shown in Figure 2,
articulate the key attributes of our user population and their user needs.
Key Characteristics
Vision:
Affects: VUI/GUI,
tasks/usage
Age:
Affects: dexterity, tasks,
aesthetics
Settings:
Affects: context,
tasks/usage
Tech tolerance:
Affects: controls/ui,
complexity
blind
kid
home
VI
teen
LV
adult
sighted
senior
street
work
old
school
low
medium
high
Coping:
Affects: tasks/usage,
settings, adoption
struggling
coping
conquering
Attitude:
Affects: tasks/usage,
adoption, aesthetics
ashamed
ambivalent
proud
Channel:
Affects: who we target;
how they encounter this
medicare
insurance
grants
OOP
Figure 2: End-user Key Characteristics
Five potential target personas emerged from our research and findings, and two
personas, described next, defined the boundary conditions for a successful
product.
Persona 1
“His vision is getting less and less clear
and he can no longer read unless he
uses very strong magnification.”
“If he had a reading device, he would
use it also to read a variety of print
material.”
James is 67 years old and lives with his wife in St. Louis, MO, in the United
States. He is a diabetic with health complications and deteriorating vision.
His hands are a bit unsteady and he is losing sensation in them. His vision is
getting less and less clear and he can no longer read unless he uses very strong
magnification; even then some common fonts are too small for him to read.
James struggles daily with controlling his diabetes. He tends to go through
cycles of being in control followed by periods where he doesn’t take care of
himself. The guilt he feels about his health is contributing to depression.
James wants a device to read the newspaper so he can stay well-informed on
current events. He likes to go out to dinner with his family, and he would like
to pay for the meal without asking his children to read the total on the receipt,
thereby regaining his head of the house role. In addition, James would like to
use coupons, distributed in the mail or newspaper, when he goes shopping. If
he had a reading device, he would use it also to read a variety of print material,
such as mail, so he could sort junk mail from bills, read greeting cards from his
grandchildren, read street signs, and read prescription instructions from the
pharmacy.
Persona 2
Ethan is 14 and lives in Swindon in the UK. He is a student, living with his
grandmother, and he was recently identified as dyslexic. He was doing pretty
well in school until the reading level increased when he turned 13. Now that
he has started high school, he is frustrated that he is in special education classes
for a portion of the day, separated from his friends.
“He is frustrated that he is in special
education classes for a portion of the
day.”
Ethan values discretion and does not want everyone to know that he is
dyslexic. Ethan wants a device that looks modern and similar to other gaming
devices that his friends have so that he would not draw attention to himself
when he uses the device at school. He has a lot of reading to do for school, so
he needs a tool to help him read books — including text books, popular books,
and magazines. In addition, he would like a device that would also allow him
to listen to music.
For both James and Ethan, having a portable device is important so that
they have the freedom to take it with them wherever they go and use it in a
variety of environments, such as in a restaurant or on the school bus. Having
a device that is light-weight, has a long battery life, and large storage capacity
are all basic features that James and Ethan care about. In James’s case, he
wants something sturdy and solid, and not too small so that it becomes hard
to operate. Ethan, on the other hand, wants something with a cool factor that
looks high-tech and is small enough to fit into his backpack.
“Having a device that is light-weight,
has a long battery life, and large
storage capacity are all basic features
that James and Ethan care about.”
Our ethnographic research therefore highlighted for us the three key elements
for a reading device: accuracy, convenience, and discretion. The device needs to
accurately capture information; it needs to be easy to use anywhere, anytime;
and it must allow users to maintain privacy in their everyday tasks. We,
therefore, had our mission: design and develop an assistive technology product
to meet the needs of both James and Ethan.
Development Stages of our Product
As with the development of any product, the Intel Reader went through a
number of design phases, with feedback loops influencing and often forcing a
rewrite of earlier specifications. Outlined here are the stages we went through
in the development of the Reader by Intel and our collaborators:
Fundamental R&D. Intel has been researching imaging technology for
decades, based largely on the need to develop visual inspection tools for silicon
microprocessor manufacturing. Image improvement, rotation alignment, the
integration of multiple images into higher resolution images, and fundamental
research in optics have all been part of Intel’s broad research efforts. Much of
this work aided in the design, testing, and debugging of the Intel Reader.
“Our ethnographic research therefore
highlighted for us the three key
elements for a reading device:
accuracy, convenience, and discretion.”
Exploration. Intel engineers began experimenting with image and optical
technology, by using lower-resolution cameras and existing OCR solutions, to
test the feasibility of capturing images of text taken with hand-held devices and
converting them into speech. Initially the team explored the use of cell phones,
and then they moved on to off-the-shelf digital cameras. The team mocked
up early prototypes and demonstrated the concept for approval. The inclusion
of targeted users as members of the design team was critical, thereby allowing
deeper insight into usage models.
Usage Research. The team expanded to include behavioral scientists who worked
with end users in their homes and workplaces to learn about their daily lives.
In this phase, as the diversity of the population was better understood, the core
usages were updated and refined.
Human Factors. Following this phase, human factors engineers pulled together
a number of potential designs that were modeled on cameras, books, gaming
devices, and other hand-held units. Flows of software user interfaces, as well as
audio cues and button placements, were proposed. These were then subjected
to user testing, whereby additional end users were allowed to hold, touch,
and provide input to plastic models and mock-ups. It was at this phase that
the insight regarding a downward pointing camera intended for use with
documents placed on a table (see Figure 4) rather than wall posters came to
light, fundamentally changing the teams understanding of how a reading
device needs to be designed. Similarly, the decision as to where to place the key
pad and other buttons for easy reach by adults and teen hands came out of this
phase of development.
Industrial and mechanical design. Following the human factors work, industrial
and mechanical designers defined the shape, color, and materials, working
through the stack-up of major subsystems and the placement of key features.
Electrical and thermal engineering. With emphasis on achieving a good end-user
experience of holding and utilizing the device, the system designers crafted
board layout and airflows to fit with the mechanical and industrial design.
Software architecture. Research into third-party applications, as well as internal
experience drove the team to use Moblin (see moblin.org) as the Linux platform
and begin working on an architecture that could include both new and existing
modules.
Alpha testing. Following six months of development, the team tested the first
integrated system, molded in plastic, using an older version Intel processor (as
the Intel Atom platform was still in development at that time). These systems
were tested with another set of users, refining each of the key design elements
while changes were more feasible.
Manufacturing. The team engaged with the manufacturing group to develop
the high-volume capacity and necessary test infrastructure.
Future development. After launch, we will continue to improve the device
further and provide updates to the product.
Technical Design Challenges
Three fundamental steps must be followed in order for the user to hear the text
that is printed on a piece of paper: the image must be captured, the image must
be converted to text, and finally the text must be rendered as audible speech.
In some cases, one or two of the above steps can be skipped. For example, if
the user already has the text in electronic form, then the capture stage can be
skipped. This is common for e-book files. Even the text-to-speech step can be
skipped if the text has already been recorded by a human. These are commonly
known as books on tape or audio books, with MP3 being the most popular audio
format.
Camera Placement
The first design and usability challenge centered on camera placement. Initial
prototypes placed the camera on the back of the device (as shown in Figure 3)
similar to the design of most general-purpose cameras.
Figure 3: End-user Key Characteristics
“We knew we needed to develop a
different solution to make the product
ergonomically friendly for all end users
of various age groups.”
When placed in the hands of end users, it was interesting to observe their
intuitive response: they stood up in order to capture pages in a book placed on
a desk. Standing was the only way for them to see what was displayed on the
device screen, as the camera was pointed to the text laying flat on the table.
When asked how they would use the device when sitting down, we observed
a very awkward twist in their wrist, in order to position the camera above the
text, and a strain in their neck to peer above the device to view the display.
We knew we needed to develop a different solution to make the product
ergonomically friendly for all end users of various age groups. Interaction
designers and engineers worked together to implement a solution to the
problem: design a vertically-mounted camera placed at the bottom of the
device. With the camera in this location, users can wrap both hands around the
device and view the display that is positioned at user eye-level when seated —
with the camera aimed directly above the printed text (see Figure 4).
?
Figure 4: Camera Placement at the Bottom of the Device
Unanticipated benefits followed from this design choice. For most users,
placing their elbows on a table assured them that the unit was level to the
surface, and such a posture provided stability while holding the units,
important for accurate imaging. For seniors, this was especially important,
enabling them to rest while holding the device. For blind users, the physical
location of the document between their elbows and directly in front of them
while seated allowed for more accurate framing of the image.
Form-Factor Considerations
In the midst of the human factors and usage research, we evaluated a number
of end-user requirements. One significant challenge concerned the size of the
device. Teens wanted the thinnest, lightest device we could design, while lowvision seniors needed buttons to be placed far enough apart to allow easy use.
Blind users had limited use for the screen on the device, though it would turn
out that most blind users wanted to have a visual display so they could share
information with sighted people. Low-vision users wanted to have as large
a screen as possible. Each of these needs pushed industrial design in various
different directions.
“One significant challenge concerned
the size of the device.”
Placement of Buttons
There are many considerations in the placement of buttons, among which are
these:
•• Placement of the buttons influences the user’s experience and learning
curve. The buttons must be close enough together such that a user does
not have to stretch uncomfortably; yet, they must be large enough and far
enough apart to accommodate users with large fingers and limited dexterity,
including users with limited range of motion due to arthritis and other
rheumatoid conditions.
•• The main function of the device, capturing images, pointed to making
the image-capturing button the most prominent button on the device.
The large button, at the cut corner on the right, also oriented the device
for a blind person, pointing the camera downward. For the teen or the
senior, pushing the button while aiming it with one or two hands was an
important consideration. This placement also was found to reduce motion
blur induced by the user’s finger movement during the image capture.
•• The team tested two-handed and one-handed usage models, determining
that having one hand free to hold content or keep a book page flat
would be instrumental to success. Following from this, the main keypad
on the device (see Figure 5) was designed to be within a thumb’s reach
while holding the device with the right hand, as almost 90 percent of the
population is right-handed.
•• Human factors research also pointed to the importance of being able to
move up or down in menu structures easily. A four-way directional pad
with variable function, depending on context, met this need. Consumer
electronic devices typically included a fifth navigation button for Select or
OK button, and therefore we located this button within the center of the
four-way direction pad.
•• For advanced usages, these five navigation buttons have multiple functions
depending on context. While playing a document, the Enter button
functions as a play/pause button. This functionality, not originally planned,
was added after user testing showed that many users expected this behavior.
Similarly, the right and left buttons have multiple functions depending
on context and usage. Holding the right button down while paused in a
reading document, will allow the users to jump one page. If the users are
playing back text, the right and left button accelerate progressively or jump
back to recently read text.
•• For the Intel Reader, a sixth button, called the back button was added to
allow users to jump from lower-level menus to higher-level menus. In
subsequent software versions, buttons would take on additional functions.
For example, the back button, when held down for an extended duration,
would return the user all the way to the Home menu, the top level of the
user interface, rather than to just go up one level.
•• Grouping of the other buttons on the device by function improved
discoverability.
•• Low-vision-related buttons, of no use to a blind person, and moderately
useful to a dyslexic user, were placed together on the lower left. These
buttons allowed for font magnification and for toggling between image view
and text view.
•• Voice speed changes were important to power users, those who are very
comfortable with using assistive technology: these users listen to content at
speeds of over 400 words per minute (four times common speech) and slow
down for complex content. Similarly, all users wanted to have Favorites and
Help easily accessible, which made dedicated buttons critical.
•• A tactile adjuster for volume allowed one handed use, with a rocker-type
button on the right side.
•• Design considerations also included responsiveness of buttons, durability,
and tactile feedback. For example, the button on the lower left for
decreasing font size on the screen is indented, while the one for increasing
font size is out dented, signaling to the users zoom in and out. Similarly,
each of the buttons is shaped uniquely by function, allowing users to
distinguish one button from another.
•• In some cases, buttons were eliminated. For example, initial designs
included a voice recorder for audio notes.
The resulting placement of the buttons is shown in Figure 5.
Hold
Power
Play
Shoot
Back
OK
Volume
View Toggle
Navigation Buttons
Zoom Out
Intel®
Options
Read
er
?
Zoom In
Favorites
Voice Speed
Guide
Figure 5: Placement of Intel Reader Buttons
Image Capture
The first major step is to capture the image of the target, which in this case
is printed text. As with any camera, the target must be in focus, properly
illuminated, and the capture time must be fast enough to prevent motion
blur. The Intel Reader’s camera subsystem was designed to be fully automatic,
including auto-focus, auto-exposure, and auto-flash mechanisms. The major
considerations in image capture are discussed next.
Illumination
The image sensor has minimum illumination requirements. In general, a sensor
that has higher sensitivity will be more expensive, and a sensor that can operate
at very low-light conditions will not have sufficient dynamic range to function
at very high illumination. For the usages we considered, ambient illumination
will vary across a tremendous range, from as low as 100 lux in a typical
residential setting, to over 10,000 lux outside on a sunny day.
The standard industry solution has been to use an integrated Xenon* flash
strobe, with an exposure time of a few tens of microseconds. The Xenon strobe
is effective, because it can produce a large amount of illumination over a short
time, with a reasonably uniform light distribution. For the Intel Reader’s usage
models, the target is generally 10 cm to 1 meter from the sensor, so the flash
strobe can be significantly lower in power than what might be found on a
standard camera that might be two to three meters from the target.
“The flash strobe can be significantly
lower in power than what might be
found on a standard camera that
might be two to three meters from the
target.”
In selecting the strobe, we also had to consider the useful life of the product.
A consistently-used Intel Reader could easily work through fifty pages a day of
text, requiring 17,000+ strobe flashes a year. Given a useful life of three years
for the device, 50,000+ would be a likely usage scenario. This drove designers
to consider long-life strobes to ensure product durability.
Intel®
Reader
?
Focus
The lens in front of the sensors determines the field of view. This field of view
can be considered as a pyramidal cone, as shown in Figure 6. Often this is
thought of as a stack of planes, where the area of the planes increases with the
distance from the sensor. However, not all possible positions within the field of
view are in sharpest focus. For any given distance between the lens and the
sensor, there will be a plane of ideal focus, as shown in Figure 6.
Since the distance between the Intel Reader and the target is adjusted by the
user, the lens must be moved relative to the sensor in order to have the target
in the sharpest focus. The auto-focus algorithm calculates the required lens
position. This algorithm must also account for slight hand movements by the
user, especially for our low-vision senior users.
Figure 6: Mockup of Field of View and Plane of
Focus
“The distance between the sharpest
plane and the plane of just-acceptable
focus is known as the depth of field.”
While the region of sharpest focus is shaped as a plane, the corresponding
planes immediately in front of and behind that plane are still in reasonably
sharp focus. The distance between the sharpest plane and the plane of justacceptable focus is known as the depth of field. For usage models associated
with the Intel Reader, the target material will often not be perfectly flat.
For example, with a thick book opened to a page near the beginning, the
distance from the sensor to the left side of the left-facing page may be several
centimeters greater than the right side of the right page. The lens must thus
have enough depth of field to account for that difference.
Preventing Motion Blur
As the user holds the device, some natural motion will be imparted to the
camera. The complete image must be captured while the image is stationary
on the sensor; therefore, the exposure time must be set correctly relative to the
potential motion of the camera. For some users, especially elderly users with
tremors, the motion may be significant. If the exposure time is too long, the
image will be blurred, resulting in poor accuracy when the optical character
recognition is attempted.
To prevent this blurring, the exposure must be fast. Of course, as the exposure
time is reduced, the amount of light hitting the sensor will also be reduced.
This drives sensitivity requirements on the image sensor, as well as performance
requirements on the illumination source.
“To prevent this blurring, the exposure
must be fast.”
Even with the relatively low weight of the device, when capturing a large
number of images, such as an entire magazine, newspaper, or book, the user
may become fatigued. In addition, the book might not naturally stay flat on its
own. The user might need some significant dexterity to hold the Intel Reader
in one hand while holding the target open with the other hand, and at the
same time not obscure the text of the target with his or her hand.
To address the user requirement of avoiding fatigue, especially for our lowvision senior group, and to allow the bound printed material to be held open,
the team developed an accessory called the Intel® Portable Capture Station, as
shown in Figure 7. The Intel Portable Capture Station has a tray that is large
enough to keep magazines or books open, with two pages exposed in the view
angle of the Intel Reader’s camera. The Intel Reader is placed into a holder that
determines the exact height above the tray and positions the camera’s field of
view.
Design of the Intel Portable Capture Station included a number of
considerations. User focus groups identified durability as a key requirement,
since this device is likely to be used in a public school setting. Portability is
another key requirement, since the user may choose to bring it to work, school,
or home.
Figure 7: The Intel Portable Capture Station
A key element of the design of the Intel Portable Capture Station and the Intel
Reader included the ability to transition from mobile to fixed usages. When
the Intel Reader is used in conjunction with the Intel Portable Capture Station,
bulk capturing of text becomes easy. However, for single worksheets and news
handouts, capturing the text by using the Intel Reader in hand-held mode is
quicker and more convenient.
Initial design included the possibility of an illumination system in the Intel
Portable Capture Station itself. The additional complexity and associated
cost of the system, including the electrical subsystems and the cost of the
illumination elements, made using the lighting system on the Intel Reader a
preferable choice.
Other user design requirements included an indented tray on the Intel Portable
Capture Station to give users a physical guide to the Intel Reader’s viewable
area when docked in the Intel Portable Capture Station. This allowed both
sighted and non-sighted users the ability to orient the target material and
assume all text is within the camera’s field of view.
The Intel Portable Capture Station was designed to have a separate button to
initiate image capture by using the Intel Reader. Because the capture button
is placed on the bottom of the tray, the user does not have to reach up high
to activate the shoot button on the Intel Reader that is placed in the holder,
about two feet above the text. Users with reduced mobility in their arms find
this feature valuable. In addition, seniors often have difficulty raising their arms
above their shoulders, and the decision to place the capture button on the tray
base was based on end-user feedback.
“A key element of the design of the
Intel Portable Capture Station and
the Intel Reader included the ability
to transition from mobile to fixed
usages.”
Optical Character Recognition (OCR)
“A key step involves finding the
natural boundaries: the spaces between
columns, paragraphs, words, and
characters.”
Once the image has been captured, the next major step is to convert the
raw image to text. This process is known as Optical Character Recognition.
OCR software packages are commercially available and one was selected for
incorporation into the Intel Reader.
The OCR algorithm must examine the pixels associated with the image
and derive the corresponding text. A key step involves finding the natural
boundaries: the spaces between columns, paragraphs, words, and characters.
Individual characters may only be a few pixels apart.
Key challenges to a highly accurate OCR process include having a sufficient
number of pixels per character, having clear focus on the characters, and
minimizing interference such as glare, etc. The differences in individual
characters, such as the lower-case letter i and the lower-case letter l may be very
subtle; therefore, acquiring a very accurate image of each character is critically
important.
“Acquiring a very accurate image of
each character is critically important.”
When capturing multiple pages, such as chapters of a book, the software is
designed to perform background OCR processing and allow users to listen
to the first few pages that have been processed, if they choose to. Typically,
by the time a user captures three or four pages of a multi-page document,
the first page is available to be read aloud. This was a design tradeoff between
optimizing for time to first sentence versus optimizing for capturing multi-page
documents; we choose the latter based on our usage models.
Text to Speech
“The ability to scale to much higher
rates will be of great importance to the
long-term appeal of any device that
reads aloud to users.”
After capturing the image of a page of text, the final stage is reading it aloud to
the user, often called text to speech. This requirement also drives a wide variety
of design decisions. Naturally, as users start to listen to more and more content,
their ability to comprehend that content will also improve. For example, a new
user may start out being comfortable with a speed of 110 words per minute,
roughly the rate of common human speech, but will later find that speed far
too slow, and he or she may eventually find that speed frustrating. However,
even users that are comfortable with 300 words per minute for simple or
familiar content may need to go much slower for complex or unfamiliar
content, such as a technical journal. Thus, the ability to scale to much higher
rates will be of great importance to the long-term appeal of any device that
reads aloud to users. The Intel Reader operates at rates as slow as 70 words per
minute and allows playback of up to 500 words per minute, with increments at
appropriate rates in between.
Rendering Existing Electronic Content
In designing the Intel Reader, we focused on the ecosystem of other consumer
electronic devices within which the device would function, as well as the
environment of electronic files for reading materials, such as plain text files or
DAISY format (described later). Connecting to a personal computer, playing
MP3 audio content, or even generating MP3 to play on other devices were
critical to the usage model. To enable this transfer, the designs included the
ability to access files on the system and transfer them on or off, by using a USB
connection to a PC or by using USB flash drives.
Imported text files can be played in the same manner as text that has been
derived by using the OCR capabilities. However, files in MP3 and other digital
audio formats require an entirely different playback mechanism. Instead of
using the text-to-speech engine, a digital audio decode engine is required.
“Instead of using the text-to-speech
engine, a digital audio decode engine
is required.”
While MP3 is a popular format for audio files, it is not the default for
accessible text. A consortium known as the Digital Accessible Information
System (DAISY) has established standards for Digital Talking Books (see
www.daisy.org). The DAISY format includes both digital audio files with
human narration and corresponding text of that file. The Intel Reader was
designed to play both text only and audio versions of these files.
Organizing Files
Over time, the user may accumulate a very large number of files. A familiar
usage model is a filing cabinet, where related files are stored in the same drawer
or folder within a drawer. As a user captures files, the files must be identified.
To simplify this identification process, we set a default where the title of a
document is identified, based on text size and placement on the page. The first
25 characters of this title become the title of the book. In a case where there
is no clear title, the first 25 characters identified become the default title. The
user may rename the file and place it in one of several categories. To distinguish
between documents with similar content, the file created also records the date
and time.
“To simplify this identification process,
we set a default where the title of a
document is identified, based on text
size and placement on the page.”
Sorting and managing content can also be done through a computer-based
architecture, by attaching the device to a computer via a USB. Using a standard
Windows* or Mac* interface to do this allows users with preferred screenreading software to navigate the device content through the tools they use on
a daily basis. Our team made a specific decision not to develop a separate user
interface for the computer, allowing users to navigate the Intel Reader through
the tools they already use.
Display Issues
For users with vision, even limited vision, an electronic display, such as an
LCD, can provide significant information. Some uses are obvious, such as
display of functional menus or a preview of the text to be captured. A less
obvious but very important use is to display the text as it is being read aloud by
the device. For users with limited vision, seeing the text along with hearing the
words yields a significantly improved reading experience. The same holds true
for users with specific learning disabilities: multiple forms of input increases
comprehension. Given that users have differing levels of sight, the font size for
the displayed text must be adjustable, even up to the point where a single word
covers the entire displayed area.
“For users with limited vision, seeing
the text along with hearing the words
yields a significantly improved reading
experience.”
“For users with specific learning
disabilities, stochastic reading, placing
one word at a time on the screen, can
be useful.”
A number of factors drive the decision on the size of the LCD panel to include.
First, the LCD panel must be large enough to be useful. Users with limited
vision will require very large fonts. For some users, reading is easier when many
lines of text are on the screen; low-vision users may have enough sight to shift
between words while reading, thereby gaining context as they go. For users
with specific learning disabilities, stochastic reading, placing one word at a time
on the screen, can be useful as this allows them to avoid scanning across a line
of text, a common challenge for readers with specific learning disabilities.
Overall, having a larger display incurs many burdens on the system: the larger
the display, the higher the cost, weight, and power consumption. One also
needs to consider the business implications. Settling on a size that conforms to
industry norms, for example, those commonly used for gaming systems, allows
the design to benefit from the economies of scale for these adjacent markets.
“The LCD panels must include
integrated backlighting, with
LED‑based illumination being the
most power efficient.”
The display will be viewed under a wide variety of lighting conditions, ranging
from dark rooms to bright sunlight. Given this requirement, the LCD panels
must include integrated backlighting, with LED-based illumination being the
most power efficient. In order to have sufficient intensity, the voltage must be
raised beyond the 12 volts provided by the main power supply, and a pulsewidth modulation must be applied to allow for variation in the intensity.
A wide viewable angle is also important: it allows users to hold the device in a
lap or observe it in the Intel Portable Capture Station while seated or standing
30+ degrees above or below the screen.
For our blind users, having a screen is not critical. Their typical usage is to turn
the screen off to save battery power and predominantly use menu voicing to
determine device status; however, a number of blind users indicated that they
would prefer to have a viewable screen to share content with sighted people
when necessary.
“Placing the Intel Reader in the center
of the document to be imaged and
raising it directly above the document
also proved useful for blind and
low‑vision users.”
Framing printed text is a challenge without audio cues to indicate whether
the text is within the field of view of the camera. When specific usage tips are
provided, blind users have more success framing the document. For example,
a tip could be advising users to hold the Intel Reader a distance from the
paper equal to the largest dimension of the page being imaged: that is, for an
8X11 piece of paper, the user is advised to hold the device 11 inches above the
document to ensure it is captured. Placing the Intel Reader in the center of the
document to be imaged and raising it directly above the document also proved
useful for blind and low-vision users in testing. When capturing documents
at home or in the office, having the Intel Reader docked in the Intel Portable
Capture Station removes the height variable, and the user is confident that
anything placed within the defined borders of the base will be captured by the
Intel Reader’s camera.
Storage Requirements
Storage requirements were defined based upon usage. For a multi-megapixel
color image, the raw images may be over 10 megabytes each. Text is a very
compact format with 1 character generally only requiring 1 byte of memory.
That same 10 megabytes can store over 5,000 pages of text, and if the text is
compressed, storage can typically be increased by 2 to 4 times more. For text
capture, therefore, the memory has to be large enough to handle capture of a
few dozen raw images.
“For text capture, therefore, the
memory has to be large enough to
handle capture of a few dozen raw
images.”
Some of the storage space must be allocated for audio files and text files.
Audio data can be tightly compressed due to gaps between words, the low base
frequency, and the relatively small dynamic range of the human voice. MP3type compression can yield files as small as 500 kbytes per minute. By far, the
least amount of storage is required for text, as one minute of text at 160 words
per minute might require only 800 bytes.
Testing showed that power users were likely to move content on and off the
device to an external drive of a computer. This pointed the team to consider
cost and to specify the size of the internal drive. Compression of images was
also a critical element, allowing the user to get good OCR accuracy from full
resolution images and then store the content once read in a low-resolution
JPEG format.
Creating a Complementary Environment
To assist in moving content into and out of the Intel Reader, a USB interface
allows direct connection to any modern computer. The Intel Reader appears
to the computer as would any storage-class device, such as is done with many
digital cameras or external disk drives. This allows direct re-use of existing tools
for movement of data files. Users can thus download content from remote
servers to their computer, and then move it to the Intel Reader. Conversely,
text captured by using the Intel Reader can be archived on the computer or
sent to other systems.
In some cases, the user may not have access to a computer. In examining
alternative data transfer methods, the USB flash drive appeared to be a great
choice. No cable is required, as the flash drive is plugged directly into the
corresponding USB host port on the Intel Reader. In addition to data transfers,
the USB host port also allows some useful USB peripherals to be connected,
such as a keyboard. This proved important in user testing for people who use
alternative input devices, such as pointer or breath-activated keyboards. The
keyboards generally function according to standard USB interfacing, allowing
people with limited mobility and special-needs computing devices to use the
Intel Reader. As an extension of this functionality, the Intel Portable Capture
Station also allows for USB connectivity, enabling the user to drive the device
while docked in the station.
“A USB interface allows direct
connection to any modern computer.”
“In addition to data transfers, the
USB host port also allows some useful
USB peripherals to be connected.”
Selecting the Computing Environment
“The Intel Reader needs a highly
flexible computing environment.”
From our architectural exploration, it became clear that the Intel Reader
must be based on a highly flexible platform. Several different vendors have
developed OCR and text-to-speech algorithms for different languages, and
additional languages are being added each year. In order to take advantage of
this continuous improvement in the OCR and text-to-speech environments,
the Intel Reader needs a highly flexible computing environment.
In addition to flexibility, the processor must provide sufficient performance to
complete the OCR algorithm within a reasonable delay. However, the size and
power consumption must be low enough to fit with the required hand-held
form-factor.
The Intel Atom processor and its associated chipsets running a general-purpose
Linux operating system provides this type of flexibility, performance, power
consumption, and size. The Intel Atom processor is an X86 compatible
processor with operating speeds above 1 GHz.
Conclusion
When developing technology to help people with disabilities become more
independent, developers face a dilemma: if they tailor the use too tightly,
the number of potential users is reduced to the point that the device is not
economically sustainable. On the other hand, if they keep the feature set too
broad, it fails to address the needs of any one community. In short, narrow
designs fail for lack of a market, and broad designs fail for lack of use. The Intel
Reader is an attempt to navigate this design challenge. The core usage model,
reading text from a page with a camera and converting it to speech, addresses
a need shared by blind, low-vision, and dyslexic users. In this way, we are
attempting to reframe the market from a subpopulation of people with one of
these disabilities to a larger population, renamed as those with Print Disability.
“We are attempting to reframe the
market from a subpopulation of people
with one of these disabilities to a
larger population, renamed as those
with Print Disability.”
We had to make choices, focusing on users with a basic set of technology
literacy skills; for example, someone who might use a cell phone or
communicate via e-mail. We also balanced the competing needs of seniors and
teens and of the sighted and those with limited vision.
The Intel Reader can also be seen as a step on the road to the future of reading
and writing. By 2020, we should expect to see a range of devices that will move
content seamlessly between print, digital, and audio. Moreover, we should
expect the cost of such technology to plummet. The key inflection point
in the cost curve will be when this technology moves from a necessity for a
disability population to a convenience for the general population. Crossing this
line will drive economies of scale similar to other common communication
and entertainment technologies. Where DVD players once cost over $1,000,
they now cost under $50. Cell phones, once the toy of the very rich, are now
included for free with a service contract. We expect that in the future, the
evolution of the Intel Reader technology will follow a similar path. Indeed, we
share a vision of this technology becoming a very low cost device, one that will
serve the disabled population and the general population. It is in this moment
of cross-over that we will see the true goal of the device come to fruition —
the establishment of an equal playing field for all people who want access to
knowledge and increased independence.
“By 2020, we should expect to see a
range of devices that will move content
seamlessly between print, digital, and
audio.”
Author Biographies
Selena Chan is a Principal Engineer and has been at Intel since 2001. She
currently manages end-user trials and market trials for the Intel Reader. Prior
work involved delivering Intel technology platforms to the medical research
community and leading external technical collaborations. She holds a Ph.D
and M.S. degree in Electrical and Computer Engineering and a B.S. degree in
Chemical Engineering. Her e-mail is selena.chan at intel.com.
Ben Foss is Product Development Manager for the Intel Reader in the Digital
Health Group, leading a team of industrial, mechanical, electrical, and software
engineers in the development of new products to help people with disabilities
be more independent. He has been at Intel since 2003. Previously, he worked
in the National Economic Council in the Clinton White House and was a
Marshall Scholar. He holds a JD/MBA degree from Stanford. Ben is dyslexic:
he volunteers his time as a board member of the civil rights organization,
Disability Rights Advocates, and Headstrong, a non-profit group focused on
issues regarding learning disabilities. His e-mail is ben.foss at intel.com.
David Poisner is a Senior Principal Engineer and has been at Intel since 1986.
He is currently the chief hardware architect in Intel’s Digital Health Group.
Prior work involved architecting nine generations of Intel chipsets and various
platform technology initiatives in the realm of power management, security,
audio, USB, storage interfaces, and LANs. He holds a BSEE degree from the
University of Kansas. His e-mail is david.i.poisner at intel.com.
Copyright
countries.
Developing Consumer and IT Platforms in a Regulated
Medical Device Environment
Contributors
Barbara Fullmer
Intel Corporation
Abstract
Alan Boucher
Intel Corporation
The Intel Digital Health Group, formed in 2005, is executing a steep learning
curve as we develop our capabilities as a medical device manufacturer. Applying
the development practices used in the semiconductor industry to complete
regulated medical devices revealed number of important process gaps that
needed to be closed.
Index Words
Some of these differences result from the very different customers served by the
Digital Health group. Some were the result of the different usage models and
potential risks in healthcare. Other differences result from the conventions,
practices and requirements of standards organizations and regulatory bodies.
Consumer Device
Medical Device
Regulatory
Design Controls
Product Development
Validation
This led to a series of complex inside-out structural modifications to the Digital
Health Group’s Product Development Lifecycle, which we discuss in detail
in this article. We also examine the effects of these changes on our group and
the challenges we faced during the development of Intel’s first FDA Class II
regulated medical device.
Introduction
The Intel Digital Health Group was formed in 2005 with the goal of applying
Intel’s technical and business strengths to meet important needs in the
healthcare industry. This was largely a new domain for Intel. We had provided
semiconductor components to healthcare customers for many years and
we had previously experimented with offering information security services
for healthcare. We also had active research programs in home health and
biomedical/life sciences. But we had never before designed and delivered fully
integrated products, directly to users, which were subject to medical regulatory
processes.
“The highest quality of life and
the lowest cost of care occur when
individuals are living independently
in their own home.”
The Digital Health Group is engaged in building products which enable
individuals to receive the care and assistance they need at home. This focus is
grounded in a philosophy we refer to as “Shift Left.” The highest quality of life
and the lowest cost of care occur when individuals are living independently
in their own home, as illustrated in Figure 1. We have focused on developing
products and services which allow individuals to receive care and support in
their own home that might otherwise be delivered in a clinical setting or an
assisted living facility.
188 | Developing Consumer and IT Platforms in a Regulated Medical Device Environment
Home Care
100%
Healthy,
Independent Living
Community
Clinic
Chronic Disease
Management
Doctor’s
Office
Quality of Life
Residential Care
Assisted
Living
Skilled Nursing
Facility
Acute Care
Specialty
Clinic
Community
Hospital
ICU
0%
$1
$10
$100
$1,000
$10,000
Cost of Care/Day
Figure 1: Shift Left, Stay Left — the Continuum of Care
Source: Digital Health Group, Intel Corporation
A large proportion of healthcare spending is dedicated to caring for older
patients who have one or more chronic diseases, such as diabetes, congestive
heart failure, or chronic obstructive pulmonary diseases (such as emphysema).
The first regulated medical device the Digital Health Group developed was
a system designed to help such patients manage their chronic diseases. Our
system was to enable self-management by the patient with the assistance of
clinicians working remotely, often as part of a dedicated disease management
team.
This first product, the Intel Health Guide, needed to be designed for use
by elders who are not familiar or comfortable with computers or other
complicated technology, and for use by skilled nurses and physicians who
provide care for these patients. The system allows the clinical care team to plan
a series of health sessions for the patient, in which the patient checks their own
vital signs, answers survey questions about their current condition, and may be
presented with educational material (text, photos, audio and recorded video.)
The patient is reminded proactively to complete their health sessions. The
clinical care team can also use video conferencing to interact with the patient,
in order to coach them and assess their condition.
In order to simplify the use of the system and ensure accuracy, data needed to
be collected automatically from medical devices such as blood pressure cuffs,
glucose meters and pulse oximeters. Collecting data from these regulated
medical devices results in classification of the Intel Health Guide as a regulated
medical device in the US, the UK, and most other countries.
“The first regulated medical device the
Digital Health Group developed was
a system designed to help such patients
manage their chronic diseases.”
“Collecting data from these regulated
medical devices results in classification
of the Intel Health Guide as a
regulated medical device.”
Developing Consumer and IT Platforms in a Regulated Medical Device Environment | 189
The Intel Health Guide system would include a purpose-built PC with a
specially designed user interface (for use by the elder in their home), a serverbased data collection system with a management application used by the
clinician care team, and a set of tools to manage the deployment and
maintenance of the system. Intel would act as an Application Service Provider,
operating the server infrastructure and back-end applications. Figure 2
illustrates the components of the complete solution.
Solution Integration
• Database ETL
• Custom export
Content and Applications
• Disease Management and RPM
• Administration and Remote Management
• Education Content, Care Plans
Network
• Broadband over Ethernet
• TCP/IP (TLS), VPN
• USB, Bluetooth™
OS, Drivers and System Software
• Windows XPe
• Device drivers
• VC Engine, VPN
IHG Hardware Core
All aspects of the system needed to be designed for the intended users, and the
entire system would need to meet the requirements for medical devices.
• Intel MB, CPU, Chipset, BIOS
• LCD with touch panel
• Plastics and HIDs e.g. Gloworm, Buttons
Telehealth Peripherals
• WeightScale
• Blood Pressure Cuff, Pulse Ox
• GlucoseMeter, Peak FlowMeter
Intel Developed
The needs and characteristics of several different user types would have to be
considered. Patients would often be elderly, unfamiliar with technology, and
living in homes with poor communications and electrical power systems. Care
managers (often nurses with varying computer skills) might be working in
central offices or from their own homes. Care manager administrators would
be assigning care managers to patients, and performing other administrative
duties. System Administrators would be responsible for technical maintenance
of databases, network connections and other infrastructure. Figure 3 illustrates
the relationships between system components and these user types.
Intel Validated
Figure 2: The Intel Health Guide System,
Version 1.0
“We found that we faced a steeper
We knew we had much to learn, but we believed the strong capabilities of
Intel’s product divisions and manufacturing organization prepared us well for
the regulated medical device industry. The development team had extensive
experience in designing PC’s, and in designing, building and operating high
reliability distributed IT systems. We had experienced software developers
who had built complex software systems for business, engineering and
manufacturing. Our corporate culture placed a strong emphasis on discipline
and quality. The complexity of Intel’s semiconductor products, the tight process
controls required in our manufacturing processes, the reliability and correctness
required of our products, and the high volumes of products we ship would
surely give us the necessary capabilities for development of the relatively simple
medical devices we planned. We found that we faced a steeper learning curve
than we had anticipated.
The direct user of Intel products in our core semiconductor business is a design
engineer or an original equipment manufacturer (OEM) who develops and
builds computer systems from Intel’s silicon and subsystem building blocks.
As such, these architects, engineers and manufacturing personnel work within
the culture of the electronics industry. They have specific expectations of
technical design criteria, product specifications, product errata, supporting
documentation, etc.
learning curve than we had
anticipated.”
Lighthouse Application Service
Provider Data Center
Patient Home
Bluetooth
Intel®
Health Guide
USB
Patient
o
C
Lighthouse Provisioning Application
Peripherals
Internet
Care Manager Office
Application Service Provider
Data Center
Care Manager
User interface
Intel®
Care Manager
Care Manager Administrator
User interface
Work Order
User interface
Care Manager Administrator
System Administrator
Intel® Health Care Management Suite
Figure 3: The Intel Health Care Management Suite v1.0
The typical Digital Health Group user, however, is not a design engineer or
manufacturing team. The users of a Digital Health Group product may be a
healthcare provider organization, a clinician, a patient, or a family member.
The other critical stakeholders in the Digital Health Group environment
are the regulatory bodies that oversee medical device development and
manufacturing. The product characteristics and the development and
manufacturing processes for medical devices must conform to the requirements
of these customers and stakeholders.
As this became clear, we learned that we needed a new set of core capabilities in
the Digital Health Group.
Digital Health Platform Design and Development
The Intel Health Guide system was initially conceived and developed under
Intel’s corporate Product Life Cycle (PLC), which has been proven over many
years of successful semiconductor design and development.
The corporate PLC extends across the business landscape at Intel – from early
market segment analysis to conceptualization of product families, through
selection, development, product delivery and finally, product discontinuance or
End-of-Life (EOL).
“The corporate PLC extends across the
business landscape at Intel.”
“Consistency and visibility improve
Intel’s product development and
roadmap stability.”
The corporate PLC is designed (as described in training material) to “drive
shared expectations and resources such as structured systems, specifications,
documentation and procedures as well as data systems and tools. This
consistency and visibility improve Intel’s product development and roadmap
stability.”
The corporate PLC provides a pathway to accomplish several major goals;
increasing development efficiencies, producing stable and synchronized
platform roadmaps, improving time-to-market and enabling organizations with
better decision making capabilities.
(P)PLC
Approvals/
Milestones
OIA/OSA
CA
Exploration
PSA
DIA
(P)POPL1
PFA
FA
(P)POPL2
Planning
Beta
Design
Complete H/W Deploy
PPS
A0-tape out
PD
PDC
PCA
Alpha
IPA
A1/A2
(P)POPL3
PIE
Development
PRA/PLA
SRA
PRQ
Production
Figure 4: The Intel Corporate Product Life Cycle
“The PLC funnel diagram depicts
the 4 phases that comprise the Intel
corporate PLC.”
The PLC funnel diagram (see Figure 4) depicts the 4 phases that comprise
the Intel corporate PLC. Slanted lines between the phases, such as between
planning and development, represent an overlap of activities between crossfunctional teams and in some cases, even organizations.
Intel’s corporate PLC has evolved over the years to support not just
semiconductor development, but all aspects of platform development
from silicon design, to subsystem building block development, to software
subsystems, and eventually, to complete client and enterprise platform design
and delivery.
“These documents enable all
functional areas in the organization
to perform the planning needed to
establish the program Plan of Record.”
Each phase carries with it a unique set of boundaries and expectations in the
life cycle. For instance, in the initial Exploration phase of the PLC, teams
focus on basic or applied research, which identifies and tests new product
concepts, architectures, features or design approaches. Uncertainty is gradually
reduced over the course of the exploration process, leading to a decision to
commit larger amounts of resources to plan a product or system.
During the Planning phase, the Product Development Team (PDT)
incorporates business analysis, user modeling and architectural requirements to
create a product definition. This takes the form of product requirements, design
documents, and quality planning. These documents enable all functional areas
in the organization to perform the planning needed to establish the program
Plan of Record (POR).
The Program POR defines the PDT’s commitments regarding product features
to be delivered at various releases, delivery dates for interim and final product
releases, product quality levels, product and program cost and pre-release
design wins.
Ultimately a decision is made within the organization to proceed to the
Development phase of the program. Here the product is engineered,
developed and evaluated against its initial requirements and other program
criteria. This phase usually involves several pre-production release gates and
formal product testing activities. Testing is conducted both internally by Intel
and in many cases, externally as our customers perform validation activities.
“This phase usually involves several
pre-production release gates and
formal product testing activities.”
Once product development is complete and a release candidate is ready for
the market, the design transfer activities begin under the PLC. Production line
qualifications, integrated system testing and yield analysis and improvement
all culminate in a series of phase gate handoffs known as Product Release
Qualification (PRQ) and Ship Release Authorization (SRA). These activities are
components of the final design transfer process, which moves the product or
platform from development into the Production phase.
The corporate PLC includes all of the steps necessary for developing complex,
high quality products. However, we learned quickly that the details of processes
that had evolved for semiconductor and computer building block development
were not always well-suited for developing complete medical devices, and were
not aligned well with regulatory requirements. Our most significant issues
occurred in the Planning and Development phases. It is here that Digital
Health encountered its greatest challenges.
Bringing the FDA into Intel required us to change our historical application
of the corporate PLC and rethink how we operated within the Digital Health
Group.
“Bringing the FDA into Intel required
us to change our historical application
of the corporate PLC and rethink how
we operated within the Digital Health
Group.”
Regulated Product Development
The design, development, manufacturing and support of any product classified
as a medical device is closely regulated everywhere in the world. In the US,
the Food and Drug Administration (FDA) is charged with this responsibility.
The quality system regulations the FDA applies are documented in the Code of
Federal Regulations (CFR), 21 CFR, Part 820 (21 CFR 820).
Outside the US, most medical device regulations are based on ISO
13485:2007, which is closely aligned with 21 CFR 820. In both of these
documents, each medical device manufacturer is required to implement
a Quality Management System (QMS) suitable for their business, which
complies with the requirements. Historically, FDA interpretation is much more
strict than ISO for requirements worded much the same.
“The design, development,
manufacturing and support of any
product classified as a medical device
is closely regulated everywhere in the
world.”
“The QSR requires medical device
manufacturers to consider quality
at the earliest stages of all areas of
product design and development.”
The FDA’s quality systems regulations (QSR) uses a total systems approach
designed to satisfy the specific safety and performance needs of each
manufacturer, product, and user market. It is intended to have a positive
impact on the quality, safety, and efficacy of the device. The QSR requires
medical device manufacturers to consider quality at the earliest stages of all
areas of product design and development. The FDA expects management and
employees of each medical device manufacturer to fully commit to the firm’s
quality management system (QMS). This commitment is vital, if the quality
system is to be effective.
There were three paradigm shifts that needed to occur when the Digital Health
Group began development of regulated medical products.
“This document has 15 subparts, each
with a different topic area, such as
Quality System Requirements, Design
Controls, and Labeling and Packaging
Controls.”
The first paradigm shift was that we needed to deeply understand the
regulations that were now applicable to us. A critical document, 21 CFR
Part 820–Title 21 Food and Drugs, Chapter 1, Food and Drug Administration,
CFR (Code of Federal Regulations), Department of Health and Human Services,
Subchapter H Medical Devices, Part 820, Quality System Regulation [2], “Good
Manufacturing Practice for Medical Devices” quickly became standard issue to
all Digital Health Group employees. This document has 15 subparts, each
with a different topic area, such as Quality System Requirements, Design
Controls, and Labeling and Packaging Controls. In addition to the regulations
themselves, there is a classification system for medical devices that, when
layered on top of the regulations, determines the level of scrutiny and the
process and objective evidence that is needed to manufacture a given product.
(Medical devices are classified as Class I, II, or III, based on the level of control
required to ensure the safety and effectiveness of the device). While there
are many requirements defined in the regulations, there is little prescriptive
direction (e.g., “Do it this way.”). This lack of specific direction caused
confusion and frustration, as employees felt the goal posts kept moving, while
the game was still in play.
The second paradigm shift was the realization that the regulations apply, like it
or not. Intel employees are known for being detail oriented and for challenging
all authority, real or imagined. While the specific application of how we
implement the regulations is subject to interpretation, the fact that we were
fundamentally subject to the regulations was not up for debate or discussion.
“We had to learn that anything that is
not documented correctly and archived
The third paradigm shift was the notion of objective evidence: what proof do
you have that you did what you said you were going to do? Intel employees are
accustomed to pointing to an e-mail, or hallway conversation, or a meeting,
as their reason for a given design or development decision. We had to learn
that anything that is not documented correctly and archived in our controlled
document repository simply didn’t happen, according to the FDA.
in our controlled document repository
simply didn’t happen.”
The Inside-Out Analysis
Faced with the paradigm shifts listed earlier, we followed the Intel standard
practice and dedicated some key individuals to own the establishment of
our QMS, with help from outside consultants. The result was an avalanche
of documentation, starting with a Quality Manual, which was supported
by a plethora of Standard Operating Procedures and Standard Operating
Instructions (SOPs and SOIs, respectively). We had to create this library
of governance and process definitions at the same time that design and
development work was being done, generally by different employees. The
exhaustive detail in the SOPs and SOIs gave us a false sense of being in control
of design and development. In practice, our maiden attempt at a QMS
resulted in an impossibly complex system that was not sustainable, nor was it
appropriate to support our business model. Our attempt at design controls was
viewed as over thought, overpriced, and overwhelming by our engineers, who
simply wanted to design a good product.
As we became aware of the burden we had inappropriately placed on ourselves,
we began to detangle the web, section by section, and to figure out what design
controls really meant for the Digital Health Group. We started with the basics,
reinforcing one of the key phrases in the CFR — “establish and implement.”
We needed to establish how we were going to do our work; we needed to
implement those processes that we defined, and we needed objective evidence
to document that we did what we said we were going to do. There was a lot of
education about the significance of writing down the plan for the work — the
how for design and development. We had to figure out the answers to lots of
questions: What did the plan need to say? Who was subject to the plan, and
why? What was covered in the plan, and what was excluded? Where were the
excluded areas addressed, if anywhere? How do we ensure that each of the
individual plans made sense, when combined with the rest of the project? We
needed more education on the importance of creating and approving the plan
before any work was started, so that the implementation of the approved plan
was clean and clear. The initial impression within the group was that the plan
creation was simply paperwork; in other words, someone else’s issue, while the
engineers did the real work, and that the plan could be done later. It took a
long time to dispel this notion. The third paradigm shift, objective evidence,
was even harder than the “establish and implement” phase of our process.
What was the right level of proof to confirm that the activities had occurred?
What level of approval was necessary for the proof? How did we ensure that
the evidence really was evidence, and not just opinion?
“In practice, our maiden attempt
at a QMS resulted in an impossibly
complex system.”
“What was the right level of proof
to confirm that the activities had
occurred?”
Overview of Intel’s Standard Product Life Cycle Versus the Code of
Federal Regulations
“We set about decomposing the
standard Intel PLC while at the same
time decomposing the CFR.”
Initially, we set about our detangling in a piece-meal fashion, going to the areas
of the most pain first. While this approach staunched the bleeding, it still did
not address the fundamental problem: what did the Digital Health Group need
to do to satisfy the CFR, while designing and developing products inside of
Intel? To get to the bottom of the issue, we set about decomposing the standard
Intel PLC while at the same time decomposing the CFR. We had to see where
we needed to make changes, and to see how we could leverage what we already
knew and were doing, to satisfy the CFR. In short, we began bringing Intel to
the FDA.
One of the first distinctions we recognized was that we were not obligated
to satisfy strict design controls while still in the Exploration phase. This was
amazingly freeing for our incubation teams — they could spend their energies
thinking about new opportunities and getting detailed ecosystem and user
understandings, without having to check they were following the regulations
each step of the way.
“This was amazingly freeing for our
incubation teams — they could spend
their energies thinking about new
opportunities and getting detailed
ecosystem and user understandings.”
“Cutting back on product features was
not permitted without justification
and evidence.”
Once we internalized the separation of exploration from design and
development, we realized that there were other clear separations within the
CFR which were not reflected in Intel’s standard PLC. We knew that we
confused our regulatory inspectors when we spoke, because we used words
that were familiar to the FDA and to ISO; but our words meant something
completely different. We used the word planning for what the FDA considered
design and we used the word design when the FDA meant development.
Another new concept for our group was formal “traceability.” This is the
process by which design inputs are matched to design outputs, and then
verified (ensuring outputs match inputs) and validated (ensuring the final
device satisfies the intended use) for completeness. Risks are identified and
categorized for potential severity during the input gathering stage; they are
traced to outputs, and the risk mitigations are verified. All of this linking —
inputs, outputs, risks, verification, and validation needs to be documented,
and exceptions need to be identified and dispositioned. Nothing is thrown
out without justification, and you have to have evidence of that justification.
Coming from an industry in which it is normal practice to delay features to
satisfy a schedule imperative, this concept of accountability for all recorded
inputs was a big shift for us. It meant we had to deliver wholly on the
requirements we defined for ourselves: a new meaning for us for the word
verification. Cutting back on product features was not permitted without
justification and evidence. This meant we had to validate that our product
satisfied its intended use by the customer, through user test results documented
with objective evidence.
Finally, and perhaps most importantly, we had to establish and document the
objective evidence that we had accomplished all of these tasks prior to release
of product to customers. Intel has always done excellent engineering work, but
we never had to prove each element of the process to an auditor or other third
party, as is needed for medical device manufacture. The evidence had to be
reviewed, agreed to, and approved by senior staff, and anything that was not
satisfied had to be identified and then dispositioned. The disposition had to be
documented as well, and it had to be readily available to an inspector.
“We had to establish and document
the objective evidence that we had
accomplished all of these tasks prior to
release of product to customers.”
A Walk Through the Code of Federal Regulations
As a medical device manufacturer who is making devices in the US but
distributing them in Europe, we are subject to both ISO and the CFR.
The two sets of regulations have many similarities, but often differ in their
emphasis. For our purposes, we had to blend these two sets of regulations to
ensure we were meeting all the imperatives we needed to. In many cases, the
CFR takes the lead, so we began our analysis by walking through the section
of the regulation that applies to design and development: 21 CFR Part 820.30:
Design Controls for Medical Devices. There are 15 subsections that we needed
to internalize and then institutionalize. We needed to tell our employees
the why, as well as the how. Deciphering the CFR was much of the why,
along with some hard-learned lessons from our employees who had previous
experience designing medical devices outside of Intel. We also learned that
institutionalization of regulations was much more successful if we provided our
engineering audience with templates and comprehensive examples of how to
satisfy the imperative.
“We had to blend these two sets of
regulations to ensure we were meeting
all the imperatives.”
Each section of 21 CFR 820.30 was analyzed carefully.
§820.30 (a) General
This is the section that defines who is subject to meeting the design control
section of CFR, and who is not — the biggest why we had to satisfy. There
are three classes of devices, as mentioned previously, as well as some special
allocation of design controls in specific classes. The most significant learning
for our group was that because we automate our device with software, we will
always be subject to design controls. Once we were able to help people realize
this, teams more or less quieted down on their protests against design controls.
“Because we automate our device with
software, we will always be subject to
design controls.”
“Once we established the Design
and Development plan as part of
the process, there was the continuing
education for the engineers.”
§820.30 (b) Design and Development Planning
“Each manufacturer shall establish and maintain plans that describe or
reference the design and development activities and define responsibility for
implementation.” This is where it began to hit home that we had to define
our plans in advance, we had to assign ownership for the elements of the plan,
and we had to maintain the plan so that it continued to drive design and
development activities. We internalized this into our Design and Development
Quality Plan, a template that ensured the key elements of the regulations
were consistently maintained across multiple programs. The development
activities matrix is the real meat of the artifact, a table that lists each design
and development activity, its owner, what the owner is responsible for, a list of
applicable SOPs or SOIs for the activity, change acceptance criteria, and with
whom the owner has to interact in order to ensure successful delivery of the
element. Once we established the Design and Development plan as part of the
process, there was the continuing education for the engineers: this was now
what they were adhering to, not an e-mail or PDT conversation.
§820.30 (c) Design Input
“Each manufacturer shall establish and maintain procedures to ensure that
the design requirements relating to a device are appropriate and address the
intended use of the device, including the needs of the user and patient. The
procedures shall include a mechanism for addressing incomplete, ambiguous,
or conflicting requirements.”
“First and foremost, CFR’s focus is on
‘needs of user and patient.’ ”
“We had to first help them identify
This is where the real essence of “What is a requirement?” started to hit home.
There are keywords in the CFR that mandate that we realign our traditional
Intel perspectives. First and foremost, CFR’s focus is on “needs of user and
patient.” We therefore had to ask ourselves who our user was. We had several,
ranging from the patient whose care is monitored by the device, to the
installer who places the device in the home, to the IT administrator, who is
responsible for the backend support of the device. These are very different
from the standard user for Intel’s core business, the design engineer or systems
OEM. Once we had the users defined, we could start to get specific on the
requirements, what we came to speak of as the what. We had a version of
a Product Requirements Document, and we had a Market Requirements
Document, standard Intel PLC artifacts. Our issue quickly became that we
had too many requirements, in too many different places, and with too many
interpretations. We compounded this problem by the way we used the word
requirement: an all-encompassing term for anything we wanted the device to
do, versus the FDA’s much more narrow definition. In order to help our teams
grasp the FDA’s meaning of requirement we had to first help them identify
where requirements came from.
where requirements came from.”
MDRs
Complaints
User
Studies
Market
Data
Clinical
Data
“Requirements come from a variety of
Defined User Needs
sources.”
Specification
Product
Figure 5: FDA Requirements for a Medical Device
FDA guidance is that requirements come from a variety of sources, such as
user needs’ studies, marketplace needs, customer complaints, and clinical
data. There may be more than one user for a product — for our first product,
we needed to consider not only the patient in the home environment, but
also the clinician and anyone else who came in contact with the product.
Requirements can be derived from initial hazard analysis; they are functional
expectations. Once the PDT understood where requirements came from, we
had to simplify our requirements and put them into a single document, to
address “incomplete, ambiguous, or conflicting requirements.” We needed to
use strong, declarative statements, and we needed to define when a statement
was a design intent (nice to have) or a requirement (device does not ship
until we satisfy it). “The device SHOULD do something,” versus “The device
SHALL do something.” When the word should is used, it can be interpreted in
many ways and that can strangle a design team and paralyze Verification and
Validation (V&V) later on. If a device should be capable of running 24 hours
a day, but it is actually only capable of running 23 hours a day, does the device
fail the requirement? Sorting through all the words of the combined MRDPRD took a very long time, and so we engaged outside consultants to assist
us with this task. We needed people with clear heads, who were familiar with
the endgame of medical device manufacture, but who were not invested in
the device, to ask the tough questions. We needed to frame our requirements
with the idea that they should be answerable with a yes or a no. An example
requirement: “The Care Management Suite functions shall be presented in
English.” This can be answered with a yes or a no, versus other items that felt
like requirements (but really were design intentions) such as “Menu structures
on the PHS will be simplified.” We started out by just cleaning up our new
PRD, tagging requirements, and making them testable. This experience was
painful and time consuming, but was essential to our success. When we had
completed the work on the Intel Health Guide, we moved onto creating a
template for future programs, so that others could start off on a good footing.
Our template had clear examples, based on what we had learned, so that the
future authors could understand the difference between a good requirement
“When the word should is used, it can
be interpreted in many ways and that
can strangle a design team.”
“When we had completed the work
on the Intel Health Guide, we moved
onto creating a template for future
programs, so that others could start off
on a good footing.”
“Now that we had clear requirements,
how did our design satisfy them?”
and a poor one. We defined some mandates, to simplify life further on
in development, and during the creation of the PRD: requirements to be
numbered sequentially, no deleted requirements without justification, no reuse
of identification numbers, proper use of the word shall, no use of the word
should, and most importantly, user requirements to live ONLY in our PRD.
§820.30 (d) Design Output
“Each manufacturer shall establish and maintain procedures for defining and
documenting design output in terms that allow an adequate evaluation of
conformance to design input requirements.”
“Our users for the device are patients
who may have visual impairments,
limited mobility, and multiple disease
states.”
“We had to get skilled at translating a
requirement into a specification.”
There were two new concepts here: documenting outputs and evaluating
conformance of those outputs to the inputs. Now that we had clear
requirements, how did our design satisfy them? This was where we redefined
specification to help Digital Health Group employees use the word in the
same way that the FDA did, so that the result of the specification could be
answered in a measurement (versus the yes or no of a requirement). The
final specification, for font size on the device, read like this: “The PHS
computer related interfaces shall use a font visually equivalent in size to 14
point Verdana.” This is an important specification; although at first it might
not appear so. Our users for the device are patients who may have visual
impairments, limited mobility, and multiple disease states. We could not
presume their vision to be 20/20, or that their dexterity was equivalent to an
athletically fit person. We had to make it easy for our user (the patient) to read
the information presented on the device. The first version of the specification
was much less precise and not measurable: there was no specific mention of
font size or type, nor any definition of where this would apply.
The second area, conformance of outputs to inputs, meant that we had to get
skilled at translating a requirement into a specification. In the example just
cited, the final version of the requirement read: “PHS user interface, PHS
education content, and PHS training material shall be suitable for use by
patients with corrected vision adequate to read a typical large print magazine,
such as the Readers Digest large print edition.” In other words, this is the what.
Now, the specification made sense: the how of satisfying the requirement was
14 point Verdana font on the PHS interface.
§820.30 (e) Design Review
“Each manufacturer shall establish and maintain procedures to ensure that
formal documented reviews of the design results are planned and conducted at
appropriate stages of the device’s design development.”
The CFR goes on to provide additional clarity on who needs to attend these
reviews, and to stipulate that the results need to be archived in the Design
History File (DHF). As an engineering company, Intel was familiar with
performing design reviews during the course of product development, but the
premise of a formal review, with specific attendees who could not be omitted,
and which was documented and archived, was a new twist. E-mail meeting
summaries, which our group was well accustomed to, were no longer sufficient.
These often had insufficient information on the attendees (what role were they
fulfilling), too much information on the dialogue, not enough information
on any decisions that were made during the review, and not archived in our
controlled document repository. “If it isn’t documented, it didn’t happen”
became a familiar refrain, particularly when the subject of design reviews
was discussed. Our initial SOP was overly burdensome, people were not
effectively trained on it, and we were haphazard in the archiving of the review
and the materials covered in the review. When we did archive material, we
were inconsistent in tracking our actions required (ARs). Were the ARs really
related to the form, fit, or function of the product? If so, then we had to have
objective evidence that they were addressed and closed. If they were related
to general process or activities (such as “Send Alan the e-mail on the new SW
code.”), then it did not need to be archived in a design review. This distinction
has taken some time to become clear in many people’s minds. In addition to
the mechanics of design reviews, we had to clearly define types of review, and
we had to start to use the review terms the way the FDA meant them. Design
Input, Design Output, and Design Transfer reviews hold a particular meaning
for the FDA, and these happen only once in a product’s development. The
employees in the Digital Health Group felt that many design reviews were
design input reviews, so again, our training programs had to carefully clarify
the new meanings we were embracing, as a medical device manufacturer.
Design Review is an area we continue to focus upon, balancing between
simplification and detail, with the goal of realizing full business value.
“Design Input, Design Output,
and Design Transfer reviews hold a
particular meaning for the FDA, and
these happen only once in a product’s
development.”
“Verification means to the FDA that
our outputs clearly match our inputs:
did we build what we said we were
going to build?”
§820.30 (f) Design Verification
“Each manufacturer shall establish and maintain procedures for verifying the
device design.”
Verification means to the FDA that our outputs clearly match our inputs:
did we build what we said we were going to build? It was during our initial
attempts at verification that we really started to understand the cost of a poorly
written specification. If we had a specification that could not be measured,
then how could we verify that the design met the specification? Therefore,
we started to get our verification team involved in the refinement of the
specifications themselves: we engaged them in the upfront work, so that they
could better perform their roles later on.
We also realized we could perform verification more efficiently. We previously
had the perception that verification was something we did only at the end of
the project, and we did not realize that there was much valuable verification
work happening upstream of the final verification. This work met the intent
as well as the requirement for thorough verification, but we had not been
taking credit for it by documenting the right objective evidence. For example,
engineering verification tests, code walk-throughs, stack-up analyses and other
engineering tasks all could play a role in substantiating verification. We did not
realize this at first, and so did some redundant tests. Recognizing that work
we were already doing would help us substantially in the end was helpful in
getting engineers to embrace the QMS. This was a clear case where we were
already doing good work, but not giving ourselves proper credit (the objective
evidence) for it.
“Engineering verification tests, code
walk-throughs, stack-up analyses and
other engineering tasks all could play a
role in substantiating verification.”
§820.30 (g) Design Validation
“Each manufacturer shall establish and maintain procedures for validating the
device design.”
“Validation, to the FDA, means that
our final product satisfies the intended
use we defined.”
“It is imperative that device design be
transferred to the manufacturing floor
accurately.”
“The Digital Health Group
Validation, as practiced in Intel’s core businesses, involves thousands of hours
of laboratory testing with commercial software, and the use of engineering
samples by validation partners. Validation, to the FDA, means that our
final product satisfies the intended use we defined. Does our product “allow
caregivers to remotely access vital sign measurements of patients at home”?
Does it “collect and store information and display it accurately on the LCD
screen”? We were so occupied with the design and development activities that
we did not internalize that the only way to validate our design, in the FDA
meaning of the word, was to test our device with real users or at least with
people who fit the profile of our real users. How do we set up those tests? How
do we recruit users? How do we document the results, and what do we do
with all the feedback received? Sorting through the information derived from
these tests, and determining which feedback meant the device did not meet the
intended use, and which feedback was a potential future enhancement, took
tremendous time that had never been planned into the project schedule.
§820.30 (h) Design Transfer
“Each manufacturer shall establish and maintain procedures to ensure that the
device design is correctly translated into production specifications.”
Design transfer simply means that product designs must be converted
into production specifications that allow the product to be manufactured
repeatably and reliably, and that was validated to meet product requirements.
This requires a correct and complete product design, clear specification of
required manufacturing process capabilities, appropriate procedures for
moving the design from the development team to the production team, and
well documented testing processes. It is imperative that device design be
transferred to the manufacturing floor accurately, so that the device quality is
not compromised. The detail necessary to accomplish this objective can vary
considerably, depending on the type and class of device, intended use, and the
knowledge transfer activities between the design and manufacturing teams. The
Digital Health Group engineering team now had to learn how to effectively
move the design into a High Volume Manufacturing environment. Further
complicating the transition was our prototyping strategy, which involved
transferring several revisions of the design to the manufacturing team in
order to support field tests. Although the engineering team often felt we were
constantly doing design transfer, we had to improve our processes to fully meet
FDA requirements.
engineering team now had to learn
how to effectively move the design
into a High Volume Manufacturing
environment.”
§820.30 (i) Design Changes
“Each manufacturer shall establish and maintain procedures for the
identification, documentation, validation, or where appropriate, verification,
review, and approval of design changes before their implementation.”
We had to learn when to start tracking changes, as mandated by the CFR,
versus when changes were simply the natural evolution of the design and not
subject to inspection. We had to establish a formal change control process, so
that we could ensure that all the steps mandated were satisfied, and that we had
the right objective evidence to support the decision to invoke the change. The
change control process we defined had attributes that we were becoming quite
familiar with, such as the definition of the right roles to be represented during
the decision making, the definition of the evidence necessary to support the
decision, and the appropriate archiving of the decision as well as the evidence.
We had twice weekly change-control board meetings, and sometimes
emergency meetings, to start to indoctrinate the team in this process. Our
biggest problem, prior to the change control process improvement, was when
to put a design element under formal design controls. Like many start-up
medical device manufacturers, we put everything under formal control, right
out of the gate. This added a significant amount of overhead and frankly, pain,
to our design teams. It made the design and development work cumbersome
and difficult for the PDT. We streamlined the process, by giving PDT two
forms of change control: Program Revision Control, leaving change control in
the hands of PDT where it belongs, and Formal Revision Control, used for
those design elements that need full control early on during product design
and development activities (see Figure 6). As the product evolves, so do the
design elements that support the design and development activities. This
variable and increasing approach has significantly reduced the amount of
overhead associated with design changes.
“We had to establish a formal change
control process, so that we could ensure
that all the steps mandated were
satisfied.”
2
Program Revision Control
1
Formal Revision Control
0
Design
Development
Transfer
Figure 6: Change Control Process
§820.30 (j) Design History File (DHF)
“Each manufacturer shall establish and maintain a DHF for each type of
device.”
This mandate is the ultimate test of “if you didn’t document it, it didn’t
happen.”
The intent of a DHF is to create a repository for all design and development
work, one place where all design inputs, design output, tests, test output, etc.
is gathered. No longer was this to be stored on someone’s computer — the
information needed to be available to the team. The contents of a DHF
provides objective evidence that we followed our design and development plan.
“This mandate is the ultimate test of
‘if you didn’t document it, it didn’t
happen.’ ”
“Finally, we could go about the task
of ensuring that the records actually
demonstrated that ‘the design was
developed in accordance with the
approved design plan and the
requirements of this part.’ ”
Our early DHFs were haphazard. We complicated them by the fact that
we had multiple document repositories, due to transitions within Intel for
document storage, as well as the reality that each engineer had his or her own
favorite repository or Web site. We had a controlled document repository that
was difficult to use, and that only accepted physical signatures for approved
documents, a true anomaly in an IT-based, e-mail-centric corporation. The first
task we faced with the DHF was corralling anything that could be identified
as a DHF item. We cast a wide net, too wide as it later turned out. The second
task was to get the right level of physical approvals on the artifacts — not
an easy task in a business group with employees in many separate physical
locations. The third task was actually loading the items into our controlled
repository and appropriately storing the physical copies. Finally, we could go
about the task of ensuring that the records actually demonstrated that “the
design was developed in accordance with the approved design plan and the
requirements of this part.”
New Product Life Cycle, Expanded and Aligned with the Code of
Federal Regulations
Based on our new understanding of both the CFR and ISO, it became obvious
that we needed our own unique PLC, separate from the rest of Intel, to ensure
that we were following the CFR and the appropriate design controls (see
Figure 7).
Research
Concept
Approval
(CA)
Product
Overview
Proposal
Level 1
(POPL1)
Product
Overview
Proposal
Level 2
(POPL2)
Production
Release
Authorization
Production (PRA)
Product
Ship
Candidate
Release
(PPC)
Authorization
(SRA)
Product
Overview
Proposal
Level 3
Product
(POPL3)
Discontinuance
Regulatory
Authorization
Clearance
(PDA)
Market Planning
Explore
Assess
Feasibility
Design and Develop
Product
Figure 7: The Digital Health Product Life Cycle
Market/Sell Product
Manufacture/Distribute
Product
Support Product
End of
Life
(EOL)
We spent several weeks decomposing the inputs and outputs for every major
activity in the Digital Health PLC, ensuring we had clear mapping to the
entire Quality System Regulation, 21 CFR 820 and clearly mapping out
dependencies and deliverables. Once we had a good handle on those aspects,
we were ready to create our own PLC. We started with the Intel corporate
PLC, because we knew that our engineers had been well trained on it and
because we knew we would have to correlate back to it when we did the
training on the Digital Health Group’s version. We renamed major blocks of
activity to match FDA and ISO terminology.
“We started with the Intel corporate
PLC, because we knew that our
engineers had been well trained on it.”
We defined the phases as follows:
•• Research includes the study of user needs, ecosystems, and new
technologies.
•• Explore includes the activities that deliver the initial investigation of a
product or platform opportunity.
•• Assess Feasibility includes the activities that analyze the business, user, and
technology feasibilities of a concept.
•• Market Planning includes the activities that define the marketing approach
and sales strategy for the product.
•• Market/Sell Product includes the activities that execute the marketing and
sales plan.
•• Design and Develop Product includes the activities that lead to the
creation of the product.
•• Manufacture/Distribute Product includes the activities that create the
final product for sale, and that transfer the product from the manufacturer
to the customer.
•• Support Product includes the activities that enable the successful use of the
product, once it is received by the customer.
We created separations between the blocks, so that the decisions, handoffs,
and design control expectations were clear. Marketing a medical device, either
in the United States or the European Union, is quite different than Intel’s
standard marketing activity. We had new restrictions on what we could say, to
whom we could say it, and at what stage in the product development life cycle
we could say it. Therefore, we also created a separation between marketing and
design and development, as well as a separation between the market planning
and marketing and selling activities.
“We created separations between the
blocks, so that the decisions, handoffs,
and design control expectations were
clear.”
“Our group needed the business
analyses contained in those business
artifacts to make solid resource
allocation decisions.”
From Feasibility to Design and Development
Now that we had a clear distinction between the research, exploration, and
design/development spaces, we needed to decide how to capture the early work
simply, in a manner that supported management decision-making, but also
supported the brainstorming and innovation we needed. We learned that there
are business artifacts that are not required by (or reviewable by) the FDA or
ISO, but we knew our group needed the business analyses contained in those
business artifacts to make solid resource allocation decisions. Intel’s approach to
these decisions focuses on the three vectors of Technology, User, and Business,
so we used those vectors as the basis of our Concept Requirements Document,
the template and artifact for capturing the early thinking. The template has
five major sections: overview, marketing strategy, users, concept functionality,
geographies, and customer engagements. We provided many examples, and
we also established the mechanism (relying on our now trusted friend, Design
Review) for moving the information across the separations between feasibility
and design and development planning, and market planning.
Quarantining Work Products
“In regulated medical development,
however, there must be a logical
firewall at the divide between the
Assess Feasibility phase and the
Design and Develop Product
phase.”
One of the fundamental challenges early in the PLC is properly transitioning
the artifacts developed outside of design controls (during Explore and Assess
Feasibility phases) into the Design and Develop Product phase. Work
products of the early phases include lists of possible requirements, design
alternatives, potential features, mockups, prototypes, etc. Because they were
developed outside of design controls, they usually do not have carefully
documented plans, objective evidence, and traceability. In other product groups
at Intel, it is perfectly natural to continue the development and maturation
of product prototypes through downstream PLC phases. In regulated medical
development, however, there must be a logical firewall at the divide between
the Assess Feasibility phase and the Design and Develop Product phase.
We can’t just carry artifacts forward into the design and development process.
Yet we need to capture the value of the work done during the early phases.
We needed a mechanism to prevent excursions from design controls, without
throwing away useful work.
In the Digital Health Group, we created a landing zone for those artifacts
under a set of internal systems and processes using Subversion* (a software
version control repository), which is a validated tool under Intel’s design
control and quality management system.
“All of these reviews are done in an
effort to assess which assets might be
transferable to our quarantine area.”
As concepts are promoted from Assess Feasibility into the Design and
Develop Product phase, we perform a series of reviews with the originating
research teams, the user experience team, the marketing team, the quality
and regulatory team, and any external vendors who may have participated
in analysis or prototyping efforts. All of these reviews are done in an effort
to assess which assets might be transferable to our quarantine area within
Subversion. Once in the quarantine area, they undergo further examination,
modification, adaptation, and evaluation for reuse, as we develop the functional
requirements, engineering specifications, patterns, and designs for the product.
Much like any technology, vendor, or software-of-unknown-provenance
(SOUP) component that might be selected for use in the design and
development process, a work product crossing from Assess Feasibility to
Design and Develop Product must be carefully selected and vetted to ensure
that the proper hazard and risk analysis have been done and that the work is
thoroughly documented and reviewed. Moreover, the V&V processes must
provide for the correct level of objective evidence and traceability to show
that the eventual released product has been properly developed under the
appropriate levels of design control.
“How are we making sure that we
have thought about the product safety
risk, as we design and develop our
product?”
Risk Management — Do it Early, Do it Often
Risk Management is a prime example of a term that means one thing to Intel
at large, and something very different to the FDA and ISO. To Intel, it means
the risk to our brand identity, the risk that the CPU may malfunction, or the
risk that the notebook may get too hot, because of our circuit design. To the
FDA and ISO, it means the risk to the user(s) of the product we’re designing
and manufacturing: will it harm them? How are we making sure that we have
thought about the product safety risk, as we design and develop our product?
The ISO places more emphasis on risk than does the CFR; we therefore work
to the ISO standard.
• Scope and Timing
• Risk Analysis Team Selection
• Communication/Reporting
(B) Risk Analysis
• Intended Use identification
• Hazard identification
• Risk estimation
(C) Risk Evaluation
• Risk acceptability decisions
•
•
•
•
Option analysis
Implementation
Residual Risk Evaluation
Overall Risk acceptance
Risk
Management
(D) Risk Mitigation
Risk
Assessment
The purpose of implementing a Product Risk Management Plan is to establish
and maintain a documented process for identifying hazards associated with a
device (the potential source of harm), safety risks (combining the probability of
occurrence of harm and the severity of that harm), estimating, evaluating, and
controlling them, determining the acceptability of residual risk, and then
monitoring the effectiveness of the control during the PLC (see Figure 8). We
learned that the FDA and ISO expect product risk management to be
implemented early and maintained throughout the entire PLC. We also
realized that we could derive benefits from embedding product risk
management into our thinking. By establishing a metric for the severity of a
given risk, and establishing the likelihood of occurrence of the risk, we could
quickly determine if the risk was acceptable, that is, as low as reasonably
possible (ALARP), or intolerable. Intolerable risks clearly had to be addressed
and mitigated, but acceptable risks were already done. By integrating this
thinking into our SOPs and templates, design teams were able to work more
effectively, putting their efforts into those areas where risks were intolerable
rather than trying to mitigate risks that were acceptable.
(A) Planning
(E) Post-SRA Risk Monitoring
• New hazards/failure modes
• Existing risks no longer acceptable
Figure 8: Risk Management Flow
Source: ANSI/AAMI/ISO 14971:2007
Defined User Needs
Device and labeling
must be easily read by
visually impared user
Specification
PHS interfaces shall
be visually equivalent
to 14pt Verdana
Output
(Component/Product)
Screens and Labeling
materials in 14pt font
Figure 9: Verification
“Initially, our thinking was that they
were similar in intent, and could
easily be run in parallel: we were
wrong.”
“If there were exceptions to the result,
we needed to clearly understand and
explain the reasons for the exceptions.”
Validation and Verification — Not at the Same Time
Verification and Validation (V&V) were not new concepts to our group,
nor to Intel, but the execution of them in a medical device manufacturing
environment was wholly different. Initially, our thinking was that they were
similar in intent, and could easily be run in parallel: we were wrong.
What we had to learn was that validation, ensuring that our device conformed
to the user needs, was insufficient if verification (ensuring that our design
output met our design input requirements) was not completed. Therefore, if we
did not verify and validate our design in sequence, we would end up redoing
a lot of work. Granted, the more often we did V&V, the better we became,
but it was an unnecessary step that we imposed upon ourselves, due to a lack
of full comprehension of what was needed. We initially had a bad habit of
pushing engineering testing “over the wall” to the verification teams. Instead
of verifying that our design outputs met our inputs, the verification teams
would do code analysis, mechanical debugging, and whatever else they could
think of to measure. In truth, correctness to specification was what we needed
to be measuring. This is when we understood the value of a clear, measurable
specification, just as in the readability versus 14 pt font case we referred to
earlier. We needed to shift our focus, from testing everything we thought of,
to improving the specification so that it was measurable, and then defining the
test that would substantiate the verification. Once defined, we had to execute
the test and provide the objective evidence that it had been satisfied. If there
were exceptions to the result, we needed to clearly understand and explain the
reasons for the exceptions. We needed to assess whether we needed a different
test, or whether the exception was acceptable, based on our specifications and
our design. All of this needed to be clearly documented and approved, before
we could consider the design to be verified.
Defined User Needs
Device and labeling
must be easily read by
visually impared user
Specification
PHS interfaces shall
be visually equivalent
to 14pt Verdana
Output
(Component/Product)
Screens and Labeling
materials in 14pt font
Figure 10: Validation
We also had adopt a definition of validation that required a user (or someone
who represented our target user group) to sit down with the device and use it.
The question we had to ask ourselves was “does our finished device correctly
satisfy the intended use?”
“The question we had to ask ourselves
was ‘does our finished device correctly
satisfy the intended use?’ ”
We had to accept that our users were more concerned about the usability of the
user interface than they were about disk access speed. Our validation efforts
needed to be focused on the real need, not our comfort zone.
Were the instructions in the manuals sufficient to enable the user to actually
understand and use the device? Or, had we assumed too much, due to our own
intimate familiarity with the device? This was the true test of all our research,
design, and development: did we really understand our users and had we met
their needs? We needed to go beyond simulation and get true feedback: can
our device be effective with our users? Validation testing is about closing the
loop. This kind of validation process was substantially more involved than what
we had initially planned and scheduled.
Complete Traceability — No Requirement Left Behind
Design traceability, to the FDA, means that inputs correlate to user needs
and risks. Outputs match inputs, and test cases support the V&V of a device.
Perhaps most importantly, traceability means that objective evidence exists
for all of these linkages, and it has been appropriately created or obtained
and properly reviewed and dispositioned. We have discussed traceability in
previous sections — how it starts with clear, unambiguous and non-conflicting
requirements. We addressed the need to define our outputs clearly, the
importance of writing a good specification, and of crafting appropriate plans
for the execution and development of the design. Even with all the work we
had done on inputs and outputs, we really did not completely understand
the concept of traceability until we needed to document it. We found that
“Traceability means that objective
evidence exists for all of these linkages,
and it has been appropriately created
or obtained and properly reviewed and
dispositioned.”
even with all our testing, there were still some things that had been missed,
things we needed to resolve. We discovered that typos can stymie the best of
teams. We discovered that requirements or specifications that we thought had
been changed were not changed in our system of record. We discovered that
any manual processes for tracking were always subject to human error — not
exactly an earth-shattering revelation — but one that cost us time and resources
to correct.
Objective Evidence Standard
21 CFR 820, Subpart D pertains to Document Controls. “Each manufacturer
shall establish and maintain procedures to control all documents that are
required by this part.” It speaks to document approval and distribution, as well
as to document changes.
“We had taken the time to establish a
controlled document repository, which
had been validated for its intended
use.”
“We learned most of these best-known-
Our challenges in this area were twofold: implementing the right
documentation and the right archival process. Our first task was to ask
ourselves whether we were creating the right documentation. We were
certainly creating a lot of documentation, but getting the teams aligned on
the appropriate documentation was challenging. Where was the objective
evidence that we had the right documentation? E-mails, meeting minutes, or
off-line conversations were not acceptable: these could not be presented to an
auditor. Helping people to understand “if it’s not documented, correctly, it
didn’t happen” was a big shift in our engineers’ thinking. Again, our templates
and team training sessions (some formal, some ad hoc) were the key to getting
this message out. Our second challenge was the archival process. Were we
following the right procedures when seeking approval of a document and were
we effectively archiving it? We had taken the time to establish a controlled
document repository, which had been validated for its intended use (software
tool validation is a different topic, and is not covered in this article). However,
we did not have an electronic signature tool that had been specifically validated
for that purpose: we were initially able to use hard-copy signatures only. This
was a real mind shift for a geographically diverse business group that thrives
on e-mails. We learned how to delegate to administrative assistants the tasks of
obtaining physical signatures and sending faxes. We learned that any employee,
no matter what his or her title, can always carry a few signed documents back
to the document control office for archiving. We learned that no one goes out
of town without putting a signature delegation authority in place, so as not to
impede our progress. We learned most of these best-known-methods (BKMs)
the hard way, as we balanced project deadlines with QSR imperatives. We also
learned we really wanted electronic signatures and that we needed to make
the investment in money, time, and people to establish a validated system that
supported this capability.
methods (BKMs) the hard way, as we
balanced project deadlines with QSR
imperatives.”
Adapting to New Ways of Working
From a software engineering perspective, there are many different
methodologies for designing and developing new software platforms. Under
regulatory requirements, the medical device industry has operated for the most
part by using a waterfall or modified waterfall development model — also
known as the Big Design Up Front model.
In a waterfall model, things happen in a cascaded and sequential fashion.
Progress may be slower as finish to start relationships pace the progress from
phase release to phase release. Modified models allow for sequential overlap
(Sashimi model) between design and implementation. Sashimi models
add some additional risk because they may require further levels of branch
prediction with regard to which phases of the design can be coded first and
how forgiving the program plan is of mid-stream changes downstream.
Regardless of the development model, regulated design and development
requires clear design inputs (product requirements, product architecture,
engineering specifications, lower-level subsystem design, functional engineering
specifications, and V&V plans) which lead to a series of formal design output
reviews, in order to provide actual design requirements for downstream code
development. Code development works from a planned release process through
a series of software milestone releases and formal V&V testing gates, until a
final Release Candidate can be produced. Completely documenting all the
objective evidence against 100 percent of the originating design inputs is a
complex and resource-consuming process.
Our software development process in the Digital Health Group improved
dramatically when we developed a clear understanding of what is necessary for
the initial Design Input review:
“The medical device industry has
operated for the most part by using
a waterfall or modified waterfall
development model — also known as
the Big Design Up Front model.”
“Completely documenting all the
objective evidence against 100 percent
of the originating design inputs is
a complex and resource-consuming
process.”
1. A clear understanding of the product or platform architecture, roles, actors,
constraints, assumptions, risks, hazards, and security threat matrices.
2. A clear set of product-level requirements, defined and approved.
3. A thorough, completed analysis of each of the subsystem designs and
including the unit test, code inspection, and functional engineering
specification needed to properly verify the product.
4. All design artifacts, decomposed in such a way that the V&V teams can
create viable test plans to present the clear and objective test evidence
necessary to support the original product requirements.
If any link in this chain breaks, then you run the risk of a process loop. Some
process loops are worse than others, and in the first development cycles of the
Intel Health Guide, we had several.
“If any link in this chain breaks, then
you run the risk of a process loop.”
Early in the V&V of the Alpha and Beta releases, it became clear that we had
missed requirements. We also had many interpretive requirements, in which
testers felt that the application should or should not function a specific way,
regardless of how we had designed it. Yet there were still other cases where we
misinterpreted the intent of a requirement.
“We approached each setback with
that final goal in mind, which was to
produce a high-quality product that
was reliable, safe, and in compliance
with all regulations.”
All of these program interrupts caused a series of redesign efforts, as well as
re-planning and re-engineering of the platform software subsystems and UI
that produced small program loops and resets. The Software Engineering
organization clearly understood the end-goal, and we approached each setback
with that final goal in mind, which was to produce a high-quality product that
was reliable, safe, and in compliance with all regulations.
We left that initial platform development experience with a new attitude
towards our own ability to control design specifications and a commitment to
drive deeper clarity into the processes that fed into our work.
Lessons Learned and New Directions
Fortunately, engineers are not generally gluttons for punishment. After the
initial release of version 1.0 of the Intel Health Guide, we stepped back and
analyzed several elements of the program that we believed we could directly
control and could significantly improve. This would inevitably produce higherquality software in a more controlled and predictable fashion. Our analysis of
the process also drove us in several additional directions.
“We stepped back and analyzed several
elements of the program that we
believed we could directly control and
could significantly improve.”
First, we had to further define the methods by which we would operate as a
software development organization:
•• Formalize our software development plan structures.
•• Develop our software subsystem designs and output processes.
•• Perform more detailed task-level, peer code reviews.
•• Implement more rigorous code version and release control.
•• Follow secure coding standards.
•• Have design effort scheduling that is risk and developer loaded by task, in
order to produce better schedule quality and predictability.
•• Rigorously adhere to the quality management system SOPs and SOIs that
control the software engineering process.
Second, we needed to separate the higher-level product requirements from the
functional engineering specifications of the platform subsystems. The PRD, as
stated earlier, is a component of the “What are we designing?” section of the
design control process. Along with the initial hazard analysis and the Platform
Architecture Document, these three pillars define what the platform will be.
Below the what level of design control, we realized that we needed to define
the subsystem and functional engineering specification outputs in such a way
that no part of the design and development of the platform was left open to
interpretation. This next-level design output would drive absolute traceability
and transparency into the how portion of the design control process. In order
to do this, we asked that each Platform Architecture Document specify the
subsystems in the platform design which would need to be thoroughly vetted
as individual lower-level design artifacts.
As a result of this change in the PLC, the Software Engineering organization
created both a Software Subsystem Design (SSD) artifact and a Systems
Engineering Specification (SES) artifact.
“We needed to define the subsystem
and functional engineering
specification outputs in such a
way that no part of the design and
development of the platform was left
open to interpretation.”
Platform architecture for client-server enterprise applications, such as the
Intel HCMS, might comprise a dozen or more major subsystems at the
architecture and platform design level. These might be represented as a Security
SSD, a Manageability SSD, a UI SSD, a Data Modeling SSD, a Peripheral
Connectivity SSD, a Communications SSD, or an Infrastructure SSD.
Each SSD is a specific how implementation design document for a given
subsystem. Not only does it deal with the next-layer design definitions, it also
represents the constraints, assumptions, standards, and implementations of
that subsystem. The SSD addresses the overall subsystem design: it defines
library interfaces, code classes, algorithms, service methods, attributes and
implementations, SOUP, component interfaces, and other functional elements
of the subsystem design.
A table in each of the SSD documents specifies both the functional and nonfunctional engineering specifications for that subsystem. It also defines the test
methods for each specification; whether they will be covered by unit test cases,
code inspections, or functional tests.
“Each SSD is a specific how
implementation design document for a
given subsystem.”
Any functional engineering specification requiring some level of functional test
coverage is automatically promoted to the SES, once the subsystem design is
completed and approved. The SES provides for a traceability link between the
PRD, the Initial Hazard Analysis, and the lower-level subsystem design itself.
It also forms the basis for the Verification Test Plan portion of the overall V&V
plan.
The SES is of course iterative through the design and development phase of the
PLC. Different subsystem designs are completed at different stages prior to the
final design output review.
During that design and development process, the SES matures — along
with the other design artifacts — providing the verification test engineers
with a clear understanding of the design outputs they will use to build
their automated and/or session-based tests. It is equally important for the
verification test engineers to work closely with the design review teams for
each subsystem design. Each SSD becomes an artifact that Test Engineering
can refer back to for the development and execution of the final test plans for
V&V.
“During that design and development
process, the SES matures.”
Improving Quality, Predictability, and Design
Assurance
“We often heard our engineers ask,
‘When is done, done?’ ”
“All of this led to a clearer definition
of the intended development work
by each engineer and a very clear
expectation of what was to be tested
and how.”
In version 1.0 of the Intel Healthcare Management Suite’s development, we
often heard our engineers ask, “When is done, done?” This question came out
of many frustrations, as we collectively ground down through several internal
release cycles and subsequent field trials of the product.
Engineering reviews of test data output with the platform V&V test teams
exposed individual tester interpretations of poorly worded system requirements
which in turn led to escalated Product Design and Systems Validation review
meetings. In addition, implied requirements and even edge boundary case
functional tests were being performed in formal V&V sessions, because of a
lack of understanding between the development and test engineering teams.
In the absence of a clear requirement, the test teams continued to push the
envelope until the product ceased to function, and then it became a product
defect. It became increasingly clear that we could not operate as an effective
and efficient team if we did not have better control over all aspects of our
design, development, and V&V processes.
After the 1.0 release, we made a number of significant improvements in our
ability to gather, define, and prioritize requirements and specifications in the
hope that this would improve the overall design methodology, test framework
implementation, test integration, and predictive control of the testing process.
All of this led to a clearer definition of the intended development work by each
engineer and a very clear expectation of what was to be tested and how.
Other improvements happened in the areas of release milestone task
definition (what elements were to be developed and when). This drove a
better understanding of development across the organization, including which
requirements and which known defects would be satisfied in each release phase.
It is essential that organizations gain agreement upfront and align to formal
testing plans under a phased development release model, so that anyone testing
any release phase of a platform will clearly understand what to expect at that
point in the code development process.
Between better design definition and cross-organizational design reviews, more
consistent code reviews, clearer software project plans, and release management
phase controls, we became much better at predicting the actual schedule of
each of the development phase gates and the overall quality of the software we
delivered at each milestone.
“We became much better at predicting
the actual schedule of each of the
development phase gates.”
Another major improvement area for us was the way we performed V&V
testing cycles at certain release milestones. In version 1.0, every software release
phase immediately entered a formal test cycle. This caused lots of internal
congestion and confusion, because testers who were running formal sessionbased testing on incomplete release code (Alpha for instance) expected to see
feature implementations and therefore logged lots of application defects.
In redefining our test processes for the next version of the software, we
defined two additional test cycles in the Alpha and Beta phase of development
known as a Developer Test (DT) cycle and a Characterization Test (CT)
cycle. Developer Tests are run by developer peers within the team, checking
each other’s code in an informal, integrated release runtime environment.
The developers run the verification test cases on their own code as well, but
in an informal manner, in order to find defects, issues, or implementation
problems with the code. After the software engineers run the DT and complete
their cleanup of known defects, the Alpha release (for example) is handed to
Verification, Validation, Technical Marketing, and other teams in order to run
CTs against that release.
“We defined two additional test
cycles in the Alpha and Beta phase of
development.”
While the CTs are being run, the developers are free to continue onto the
next development phase. As defects arise from the CTs, they are addressed as
a part of the Beta development phase (in this example). The benefit here is
that we make multiple informal test passes through the code-base during its
development lifecycle so that by the time we reach actual Release Candidate
status and perform formal V&V under our plan, all of the groups involved in
the development of the platform clearly understand the expected features and
the expected test-plan execution suite. As a result, this produces a much higher
confidence level in the expected outcomes.
All of these steps lead to fewer Release Candidate builds. Our development
schedules improved dramatically and the quality of our software improved
four-fold over the previous process, with regard to the number and severity of
the defects found.
“The quality of our software improved
four-fold over the previous process.”
Like building a house, the foundational elements are the most important thing.
As the work progresses, checks and balances between the architect, the builder,
various subcontractors, and building inspectors ensure a quality outcome.
Software development is no different. If you understand the elements of
each phase of the design and review and plan for them accordingly, your
developers will always know that they have successfully completed the product
requirements with a high degree of design quality and assurance and will in fact
know when done is actually done.
“Your developers will always know
that they have successfully completed
the product requirements with a high
degree of design quality.”
Conclusion
“Inflection points offer promises as well
as threats.”
“Designing processes to meet the
requirements of the healthcare
industry presented a set of new
challenges.”
Implementing a regulated product development process was to say the least,
challenging. Early assumptions and confidence in our own PLC, technical and
manufacturing capabilities gave way to uncertainty and frustration. Andrew
S Grove, the former CEO and Chairman of Intel Corporation, wrote a book
on the subject of organizational tension and reconstruction entitled Only
the Paranoid Survive: How to Exploit the Crisis Points That Challenge Every
Company, in which he discusses the concept that …“inflection points offer
promises as well as threats (to your business survival). It is at such times of
fundamental change that the cliché adapt or die takes on its true meaning.”
The Digital Health Group had a deep commitment to product quality from
its inception. During our first product development cycle we pushed ahead,
resetting our process several times, focusing on doing the right things right, and
in the end, producing a high-quality, safe, and effective product that adhered to
the regulatory requirements set forth by the CFR and other regulatory bodies.
It became clear to all of us that we had no choice but to adapt our development
processes if we were to be an effective medical device manufacturer. Designing
processes to meet the requirements of the healthcare industry presented a set
of new challenges; we had to learn to operate within a much more constrained
and formalized development process, while still developing innovative products
and working efficiently.
Before beginning our next product development cycle, we made a number
of significant decisions and structural changes to our PLC, our phased
development methodologies, our SOPs, SOIs, and development artifacts.
We completely restructured the way we capture, measure, and implement
requirements and specifications. We also integrated other structural
development process improvements, such as Security Design and Development,
Risk Management Design Assurance, Labeling and Documentation Workflows
into the overall process, instead of making them parallel breakpoint activities.
“We are now adding increased focus
We continue to practice user-centered design as we develop next generation
products for home health. Our design and development processes have
converged during our first development cycles to fully meet regulatory
requirements. We are now adding increased focus on predictability and
efficiency in our design and development activities. Our constant goal is the
delivery of products that help to improve the health and quality of life of the
people who use them, while lowering cost and improving access to healthcare.
on predictability and efficiency in our
design and development activities.”
References
[1]
The Intel Corporate Product Life Cycle (PLC), Intel Corporate Program
Management office, Intel Corporation
[2]
The World Health Organization. “How can chronic disease
management programmes operate across care settings and providers?”
In WHO European Ministerial Conference on Health Systems, Tallinn,
Estonia, 2008 Debbie Singh. Available at www.euro.who.int
[3]
21 CFR Part 820–Title 21 Food and Drugs, Chapter 1, Food and Drug
Administration, CFR (Code of Federal Regulations), Department of
Health and Human Services, Subchapter H Medical Devices, Part 820,
Quality System Regulation. Search for CFR Part 820. Available at
www.accessdata.fda.gov
Authors’ Biographies
Barbara Fullmer is Director of Product Development Controls at Intel
and has been with company for eight years. She has been working in the
semi-conductor industry for over 21 years. Barbara has spent 16 years in
various planning functions, from wafer fab planning to multi-national
capacity commits for fab, wafer sort, assembly, and test. Prior to joining
the Digital Health Group in 2005, Barbara worked in the Technology and
Manufacturing Group as the Strategic Capacity Planning Demand Manager.
She has received various awards at Intel for process improvement, including
re-engineering aspects of the long-range planning process. Prior to joining
Intel, Barbara worked at Affymetrix, a bio-medical device manufacturer, as the
Manufacturing Planning Manager. Her e-mail is barbara.h.fullmer at intel.
com.
Alan Boucher is the Director for Software Architecture and Engineering
in the Digital Health Group. He is a 21-year veteran of Intel where he has
focused on the healthcare market since 1999. Throughout his career, Alan has
led numerous software engineering and architecture teams for various Intel
platform groups and has managed field systems and network engineering teams
worldwide for more than half his career. He received the Intel Achievement
Award (IAA) twice (2002 and 2005) for leading the Technical Solution
Blueprint team and for technical contributions to the Mobilized Software
Initiative. His e-mail is alan.boucher at intel.com.
Copyright
countries.
9 781934 053232
7
35858 21143
7
$49.95 US
Copyright © 2009 Intel Corporation. All rights reserved. Intel, and the Intel logo, are trademarks of Intel Corporation in the U.S. and other countries.
SEPTEMBER 2009
Enabling Healthcare in the Home
vol 13 | issue 03 | SEPTEMBER 2009
ISBN 978-1-934053-23-2
Intel® technology journal | ENABLING healthcare in the home
More information, including current and past issues of Intel Technology Journal, can be found at:
http://developer.intel.com/technology/itj/index.htm
Intel® Technology Journal
9/4/09 8:28:45 AM

Intel® Technology Journal: Enabling Healthcare in the Home

Transcription

Similar documents

CF-SX4 Fact Sheet

See more

Taming Your Indicator Consumption Pipeline

chimb.ca

FestusManor Good News Gazette Update

Lanvera Borland-Groover Clinic Case Study

Media Engine - WDL Systems

InBody720 Spec Sheet

Telmap - Software Sources Ltd.

Sports/Activity Physical Form