Mais conteúdo relacionado
Semelhante a Connected Health Interoperability Platform_White Paper_Cisco UCSF_2016 (20)
Connected Health Interoperability Platform_White Paper_Cisco UCSF_2016
- 3. Page 1 of 8
The Case for Connected Health
Healthcare organizations face increasing pressure to keep costs of care down while providing
the highest quality care. Caring for a population of patients with a chronic disease, like asthma,
CHF, or diabetes requires good data quality, data analytics, and data liquidity, as well as resource
coordination. While no available population health tool can solve everything on its own, several
applications working together seamlessly can. Improving the consumer experience and engagement
with healthcare will similarly require a seamless end-to-end solution comprised of many different
applications working together.
Imagine what will be possible when EHRs, mobile health apps and devices, and wearables all work
together and pass data between them.
White Paper
Contents
The Digital Healthcare Ecosystem Today
Connected Health Interoperability Platform
Cisco Digital Platform
Conclusion
2
4
6
7
© 2016 Cisco and the Regents of the University of California. This document is Cisco Public.
Referral Management
• What if primary care doctors were able to quickly identify the right specialist for each patient who needs one?
• What if all of the necessary information was sent with that referral so that a patient never again drove 400
miles only to show up and waste a visit because an ultrasound report is missing?
• What if primary care doctors were always notified of specialist visits after the patient was seen?
• What if your hospital could report on, track, and analyze all referrals made and completed to optimize resource
allocation?
Care Collaboration
• What if your primary care doctor, primary oncologist, consulting oncologist, palliative care doctor, physical
therapist, occupational therapist, neurologist, cardiologist, and orthopedist could all communicate together
about your care through a chat tool so that you didn’t have to be the router of information?
- 4. Page 2 of 8
• What if your oncologist, radiologist, and pathologist could all view the same CT scan and laboratory data to
make a treatment decision together in that chat tool, despite being 250 miles apart?
• What if you could be part of that chat?
• What if the chat could immediately switch to a video conference to help make such an important decision?
Patient Experience
• What if you had one portal to view all of your health data instead of having to log on to five different ones?
• What if you could schedule appointments with any of your doctors from that one portal? What if that visit could
be an immediate video visit?
• What if the temperature, blood pressure, weight, blood glucose, and activity data that you’re tracking at home
could help your doctor diagnose you?
• What if the reminder sent to you to get a flu shot or colonoscopy was accurate?
Precision Medicine in the EHR
• What if the application used to monitor your cardiac pacemaker automatically could pull in your medication list
and other medical history from the EHR?
• What if the application used to monitor your continuous glucose data and insulin pump data could write your
most recent insulin pump settings directly into the EHR?
• What if your health data could be compared in real-time to thousands of other cancer patients like you to help
decide what treatment to use next?
• What if while prescribing a medication, your doctor already knew how much each medication would cost you
and what the chance of its effectiveness would be?
• What if your health data could automatically populate a system that matched you to the clinical trials that were
options for you?
Health Data Security and Privacy
• What if you knew everyone who had access to your health data, all the time?
• What if you had one place from which you could allow people to access your health data?
• What if you got a notification every time somebody new accessed your health data?
The Digital Healthcare Ecosystem Today
Existing technologies leave us unable to meet the needs presented above. EHRs were built to support episodic,
fee for service care provided within a single institution. EHRs were not built to support population health, patient
engagement, data from consumer apps and sensors, and collaborative patient-centered care across institutions.
To realize these needs requires a seamlessly interconnected ecosystem of commodity technologies, such as
electronic health record (EHR) systems, adjunct hospital information systems such as Lab Information Systems
or Imaging Systems, medical devices, consumer health devices, sensors, smartphones, tablets and an array of
computing, network, and storage infrastructure.
Institutions such as the Cleveland Clinic, Johns Hopkins, Duke University, and others have demonstrated
capabilities to develop, integrate, and implement innovative healthcare applications. However, nobody has yet
provided a solution that scales beyond just a small number of institutions. Inconsistencies of EHR implementations
and lack of interoperability standards leave groundbreaking innovations stranded at their origin, unable to reach
broad markets. The private sector is full of digital health startups, but they struggle with costly implementations due
to unique integrations required at each institution. Partially to avoid this cost, many startups target their apps solely
on the consumer market, losing out on the potential benefits of integrating these consumer health functions with
the healthcare delivery system.
© 2016 Cisco and the Regents of the University of California. This document is Cisco Public.
White Paper
- 5. Page 3 of 8
Many healthcare organizations want to become more innovative in the way they deliver care and engage with
their customers, but implementing and integrating new solutions are very costly. They thus shy away from
experimentation, herding toward the solutions which already have the most proven ROI, stifling the potential
validation of newer technologies.
Other industries have fueled innovation through a digital data and services exchange economy. Examples outside
of healthcare are plentiful: Amazon.com in retail, Google for advertising, Twitter for media and Salesforce.com for
sales & marketing. Open application programming interfaces (API’s) are the de facto method for exposing data
and electronic services in those industries. There is increasing recognition that API’s are needed to accelerate
healthcare innovation1
.
Figure 1: Interoperability is the Challenge in Digital Health2
People Navigate the Healthcare Journey; Their Data Does Not
But healthcare is more complex than many other industries and there have been few widely-adopted
interoperability standards for healthcare data. This has been a significant barrier to creating open healthcare API’s.
Other barriers include the fear of heavy financial penalties from privacy breaches and the walled garden approach
of many EHR vendors. Moreover, it has only been in the past few years that the majority of healthcare institutions
have even implemented EHR systems, creating a system where health data is off of paper and into digital format5
.
Health Level 7 (HL7), a global healthcare data interchange standards organization, has a loose interoperability
data standard, eponymously named HL7, which has failed to enable semantic interoperability across the
healthcare system. While all related patient data is available, there is no consistent, repeatable way to exchange
that data across multiple organizations. While other specifications such as CCD and Direct and regional health
information exchanges allow for limited interoperability amongst healthcare institutions, digital health innovators do
not have a means to access patient information.
HL7 has been working on a new, lightweight standard called Fast Healthcare Information Resources (FHIR). FHIR
simplifies the data model by breaking down the data into its simplest, usable form, e.g. Patient, Problem List,
Medication List and Allergy List. More complicated data exchanges are possible by combining simpler objects into
a Document construct. The data model is represented as either XML (eXtensible Markup Language) and/or JSON
(JavaScript Object Notation), formats common in many other industries and well understood by modern software
developers. FHIR also specifies an efficient, yet simple, approach called REST (REpresentational State Transfer)
to exchange data resources between two systems.
HL7’s plan is to publish the official FHIR specification in 2017. As of September 2015, the second, draft version of
FHIR is being utilized in pilot projects by several organizations. Several notable organizations are advocating
© 2016 Cisco and the Regents of the University of California. This document is Cisco Public.
White Paper
* The US Department of Health and Human Services has a dashboard of Health IT statistics that reflects EHR adoption, which is currently >90% across the US:
http://dashboard.healthit.gov/quickstats/quickstats.php
- 6. Page 4 of 8
FHIR: The White House; U.S. Department of Health & Human Services’ Office of the National Coordinator (ONC);
the JASON Task Force, an independent group of scientists who advise various federal agencies; and the Argonaut
Project, an alliance of EHR vendors, most notably Cerner and Epic and a few leading healthcare institutions. Epic
and Cerner, two of the largest EHR system vendors, have minimal (read only) FHIR implementations in the latest
version of their software.
Roadblocks to Digital Health Innovation
We believe that the adoption of FHIR as a standard is necessary, but not sufficient toward creating a scalable and
interoperable health ecosystem to accelerate digital health innovation. In particular, we identify these roadblocks
that are impeding digital health innovation and slowing adoption:
• Lack of Semantic Interoperability: Both HL7 and FHIR support what HIMSS calls foundational and
structural interoperability: data can be exchanged (HL7) and uniform & structured exchange is possible
(FHIR). Semantic interoperability is the ability to exchange information and allow the information to be used6
.
While FHIR has been an improvement, it is only a stepping stone to semantic interoperability.
• Decentralized Patient/Consumer Data: Patient data today typically resides across different EHR’s. A patient
can be seen by his/her primary care doctor in a family practice clinic, visit urgent care at a regional health
system, and see specialists at an academic medical center. In addition, health data is no longer limited to the
EHR. Consumer medical devices, wearables, apps, and sensors generate streams of data that contribute
information about a patient’s health status. Data from these sources reside in the cloud or on a smartphone.
Each system has its own set of patient/consumer identifiers as well as unique health data models and putting
together a holistic picture of a patient has yet to be achieved.
• Hospital/Clinics IT Resource Limitations: Hospitals and healthcare systems have spent billions of dollars
over the past 5 years to implement EHR’s. Most healthcare IT organizations are stretched to keep these EHR’s
running. In other industries that participate in the API service exchange economy, significant resources are poured
into supporting their API infrastructure. Very few hospitals and clinics can justify funding the resources needed to
support a robust API infrastructure. Combine that with a lack of compelling digital health applications that easily
integrate with EHR API’s, there is no way to justify the expenditure.
• Limited Healthcare API Enabled Solutions: The majority of interoperability solutions today still use HL7
interface engines to exchange data from an EHR system. While some have API capabilities, the functionality
is limited. A hospital can readily share data to ancillary systems, e.g. lab systems or imaging systems yet
the majority of hospitals and clinics are unable to share information with one another. Many EHR vendors
are now providing API capabilities that allow access (typically read-only) to its EHR patient data, but without
an interoperability standard, there are few hospitals that are utilizing those API services. As a result, only a
miniscule number of digital health applications can be integrated with hospital EHR’s.
• HIPAA and Security: Many healthcare applications, especially those intended for clinical use, must follow
rigorous security practices in order to meet HIPAA requirements. Each institution that wishes to adopt
those applications must thoroughly review them for security vulnerabilities prior to implementation. With the
exponential rise of IT security threats, hospital IT security offices are backlogged and have little bandwidth to
conduct applications systems reviews, and are unwilling to take on additional risk.
Connected Health Interoperability Platform
UC San Francisco’s (UCSF) Center for Digital Health Innovation (CDHI) and Cisco are working together to break
down the barriers to digital health innovation. UCSF is a leading university dedicated to promoting health worldwide
through advanced biomedical research, graduate-level education in the life sciences and health professions, and
excellence in patient care. CDHI’s mission is to improve health by collaborating with innovators from UCSF and
beyond to envision, realize and evaluate game-changing digital health technologies. Cisco is the worldwide leader
in IT that helps companies seize the opportunities of tomorrow by proving that amazing things can happen when
you connect the previously unconnected.
© 2016 Cisco and the Regents of the University of California. This document is Cisco Public.
White Paper
- 7. Page 5 of 8
With our partnership, we are building a Connected Health Interoperability Platform (CHIP) that will connect digital
health innovations with dispersed patient-consumer data and combine with powerful analytics to revolutionize
healthcare. The CHIP will consist of a digital health application market place, a secure, cloud hosted data
interoperability system across EHR’s/devices/apps and API services that enable feature rich, interconnected
healthcare application development.
Figure 2: A Connected Healthcare Interoperability Platform
Health Applications Marketplace
The CHIP Health Applications Marketplace will provide a selection of applications that address some of today’s
pressing healthcare problems. We are initially focusing on Referral Management, Care Collaboration, and
Population Health. Solutions come from UCSF, Cisco, and other partners who have built innovative healthcare
applications that are reviewed and vetted by a combined team from UCSF’s and Cisco’s Healthcare teams. Any
healthcare institution subscribed to the CHIP will have ready access to all applications in the marketplace. Utilizing
a flexible and customizable access rules engine, any application in the marketplace will be able to securely
consume data from or write data to the organizations subscribed to the platform.
Digital Platform Services
The CHIP provides core hardware and software services running on Cisco’s secure, scalable, cloud-computing
infrastructure. As the global leader in IT, Cisco’s infrastructure is highly available and scalable with unparalleled
security and performance. The same infrastructure is utilized in finance, retail, and energy sectors. Cisco’s
Healthcare Advanced Services team and partners will engage with each subscribing hospital or clinic and connect
their healthcare systems to the CHIP utilizing technologies available (HL7, SOAP, REST). Cisco manages and
maintains the CHIP cloud infrastructure.
The core capabilities of the platform include the following:
Core Data Services
• Holistic Patient Data Model: Patient data conforms to data models championed by the ONC. An extended
consumer data model contains health information from outside the EHR.
• Normalized Health Content: Semantic interoperability will be achieved by utilizing healthcare data normaliza-
tion techniques developed by the University of California health system, so that CHIP presents patient informa-
tion in a consistent fashion, even though underlying EHR’s may use different encoding mechanisms.
© 2016 Cisco and the Regents of the University of California. This document is Cisco Public.
White Paper
- 8. Page 6 of 8
• Provider Registry: All healthcare workers will have a unique identifier. Current US standards only support a
national provider identifier (NPI) for standard transactions, which leaves out many types of healthcare workers,
such as nurses.
• FHIR Server: API’s support the data models and services from the ONC’s Interoperability Roadmap and the
Profile defined by the Argonaut project.
• Global Master Patient Index: A globally unique patient identifier links patient records across different institutions’
EHR’s, as well as across consumer health apps and devices.
Security Services
• Authentication: Single Sign On (SSO) authentication services use standards like OpenID so users can be
authenticated against existing EHRs and other systems containing user data (such as Google ID or Fitbit ID).
This provides a seamless user experience.
• Authorization (OAuth 2.0 Services): Any external applications utilizing CHIP data must authenticate using
OAuth, that is, given permission by the user. The external applications must specify what data it is accessing
and how it will be accessed. Permissions can be revoked by the user at any time.
Core Application Services
• Patient-Consumer Portal: Allows a user to view an integrated set of his/her health information in one place.
Two factor authentication will be required for portal access.
• Workflow Engine: Coordination of processes is a key capability needed to intelligently combine different appli-
cations in support of healthcare.
Infrastructure Services
• Secure Networking and Data Access: All personal health data is encrypted in transit. Data remains at its
source accessed through data virtualization. All access is logged and audited, with advance analytics applied
to find suspicious instances of data access.
Development Sandbox
CHIP aims to accelerate digital health innovation. To achieve this, a development environment will allow healthcare
software developers to create software utilizing the CHIP API’s.
Our development site has all our API’s and data models documented. It contains sample code in Ruby, JavaScript,
Java, .Net, Objective-C, and Swift. There is a development sandbox FHIR server available, populated with realistic
patient and consumer data. Developers will be able to sign up and retrieve development keys to start coding
immediately.
Once developed and tested, software can be submitted for eligibility review to the CHIP Healthcare Applications
Marketplace. The software will be vetted, end-user tested, reviewed for security, and if necessary, recommended
for scientific, clinical validation. Once approved, applications have access to data from every institution subscribed
to CHIP.
Cisco Digital Platform
Built upon proven technology within the Cisco Portfolio and Cisco Partners, CHIP provides a comprehensive set of
capabilities to solve interoperability.
• Service eXchange Platform (SXP) provides a comprehensive cloud solution for delivering business process
and automation as a service. SXP rapidly connects users, applications and data to form a highly secure enter-
prise-grade cloud that delivers business services faster, at lower cost and at scale.
• Data Virtualization brings agile data integration software that makes it easy to abstract and view data, no
matter where it resides. By utilizing the Data Virtualization Integrated Data Platform, CHIP can query all types
of data across the ecosystem as if it were in a single place.
• Cisco Integration Platform quickly connects and automates processes that span on-premise and cloud-
based data, applications and IoT devices through a lightweight service bus and end-to-end API management.
© 2016 Cisco and the Regents of the University of California. This document is Cisco Public.
White Paper
- 9. Page 7 of 8
• Cisco Internet of Everything Data System (IDS) is infrastructure software focused on data handling within
an IoE system. It allows bidirectional communication between devices, processing modules and applications.
Applications can consume source data in an event or query based fashion. Applications can also receive notifi-
cations of events and state changes. The IDS has the ability to deploy logic throughout the CHIP with software
and compute functions in a distributed manner at the edge, in a fog node, or in the cloud.
• Connected Analytics brings analytics platform that delivers predictive, actionable insights from high-velocity
streams of live data from multiple sources, enabling real-time governance and immediate actions.
• ServiceGrid brings an integration platform that connects the systems of providers, payors, and external ser-
vice providers to enable end-to-end service delivery over entity boundaries. ServiceGrid captures and enforces
workflow for complex multi-entity interactions (such as eReferral) to ensure compliance and seamless patient
experiences.
• Medical Device Exchange Service (MDES) provides an integrated end-to-end, standards-based solution that
facilitates patient-centric access to medical records. As Cisco’s Health Information Exchange (HIE) solution,
MDES gives healthcare professionals from multiple institutions access to patient data from previously discon-
nected systems with incompatible formats and disparate medical terminology. Now providers can quickly and
easily access and review a patient’s medical data gathered by different applications and stored in separate
locations.
Conclusion
The Connected Health Interoperability Platform is currently under construction, but we are demonstrating our FHIR
API’s at the API Bar of the HIMSS 2016 Interoperability Showcase. UCSF Health will be the first institution live on
CHIP, targeted for late summer 2016. We know this is audacious and bold and we believe collaboration is needed
to accelerate digital health innovation.
We invite you to join this exciting movement and become part of the health innovation ecosystem as:
• A healthcare institution or payor that wants to subscribe to the platform to give their patients and physicians
access to the best digital health applications
• A device or wearables maker that wants to connect your customer’s data to their electronic health record
• A software company with a great consumer health application that could benefit from patient data from across
provider institutions
• A clinical researcher with a new clinical decision support algorithm that s/he’d like to make widely available
• A citizen scientist or a student with a great idea for a healthcare app
Please, visit us at http://digitalhealthplatform.org and sign up to learn how you can join us in revolutionizing
healthcare.
© 2016 Cisco and the Regents of the University of California. This document is Cisco Public.
White Paper
- 10. Page 8 of 8
References
© 2016 Cisco and the Regents of the University of California. This document is Cisco Public.
White Paper
1. https://www.healthit.gov/sites/default/files/ONC10yearInteroperabilityConceptPaper.pdf
2. Walker, J., Pan, E., Johnston, D., & Adler-Milstein, J. (2005). The value of health care information
exchange and interoperability. Health Affairs, 24, W5.
4. Furukawa, M. F., King, J., Patel, V., Hsiao, C. J., Adler-Milstein, J., & Jha, A. K. (2014). Despite
substantial progress in EHR adoption, health information exchange and patient engagement remain
low in office settings. Health Affairs, 10-1377.
5. http://www.fiercegovernmentit.com/story/healthcare-api-task-force-gets-work/2015-12-07
6. http://www.himss.org/library/interoperability-standards/what-is-interoperability
3. http://healthaffairs.org/healthpolicybriefs/brief_pdfs/healthpolicybrief_82.pdf