Transcript Document

May 14, 2014
PAeHI’s 10th Annual
HEALTHCARE IT SUMMIT
‘Connecting Pennsylvanians for Better Health’
Aaron Seib, NATE CEO
1. About NATE
•
•
History
Member States
2. Legal Barriers
• Model Modular Participants Agreement
• Open Library for Health Information Exchange
3. Policy Barriers
• Consent
• Patient Mediated Exchange
4. Technology Barriers
• CONNECT: Open Source Community
About this talk …and NATE
The mission of NATE is to assist state HIE officials, individually and collectively, in
serving the public interest and achieving the following fundamental HIE goals in a
responsive, efficient and cost effective manner, consistent with the wishes of its members:
• Protect the public interest;
• Develop a roadmap that addresses and eliminates the legal, policy and technical barriers
that inhibit HIE between entities in a state and across state borders;
• Facilitate HIE Governance as the path to trusted exchange through the convergence of
disparate trust models, policies and processes;
• Collaborate with all interested participants to initiate and/or participate in the development
of HIE national standards and best practices;
• Promote the reliability and sustainability of the HIE industry; and
• Support and improve state regulation of HIE.
About me…and this talk and some coincidences
• Born and raised in Pennsylvania
• Went to college at University Park where I got a degree in
Management Science and Information Systems.
• 20 years Professional Experience in Health information Technology.
• Worked for HealthAmerica and Synertech here in Harrisburg back
in the mid-90s; then in Disease Management and Clinical Research
for the NCI;
• It was while I was at the NCI in 2004 --- 10 years ago that President Bush signed Executive Order 13335:
Incentives for the Use of Health Information Technology and
Establishing the Position of the National Health Information
Technology Coordinator
Ten years ago my son Tyler was Diagnosed with Autism
• About the time Bush
signed 13335 we got a
definitive Dx of Autism
for Tyler
• Over the ensuing years I
was stunned to learn that
the state of art for treating
Autism amounts to trial
and error.
• Made a commitment to
work on anything I could
to further the vision of
what has come to be
known as the learning
health system.
Motivated
• Had the tinniest of footholds on the Phase 1 Prototype
Architectures of the NHIN back in 2005
…and did everything I could to be involved in
related work since, including:
• Worked with the ONC as the Trial Implementation Manager
for the NHIN;
• Was the interim CEO for the National eHealth Collaborative;
• Worked for the State of California (starting in 2011) as the
state’s HIE Policy SME leading a number of initiatives
including what became NATE.
History of NATE
• In the Spring of 2011, State Leaders on the West
Coast began to interact – eventually forming an
affinity group that sought to leverage the ONC’s
State HIE Grantee Cooperative Agreement
• One of the Program Information Notices (PINs)
required State Grantees to allocate resources to
“enabling interstate HIE”
• This affinity group of states collaborated on a
proposal to pilot mechanisms for multi-state
trusted exchange – resulting in a multi-state grant
award known as the Western States Consortium.
7
The Western States Consortium
 ONC State Health Policy Consortium Project focused on the governance
needed to facilitate and support Interstate HIE, using Direct Secure
Messaging


Resolve policy issues, especially those related to privacy, security and data
use
Develop standards and requirements for trusted services, beginning with
Direct Secure Messaging
 Core States: Alaska, Arizona, California, Hawaii, Nevada, New Mexico,
Oregon and Utah
 Pilot States: California and Oregon
 Affiliate States: Colorado, Florida, Georgia, Idaho, Michigan, Ohio and
Washington
8
Success!
• At the end of March in 2013 we had satisfied the requirements of
our grant.
• We had established a ‘trust community’ that enabled each State to
independently govern HIE within its state while facilitating crossboarder exchange when appropriate.
• Further we had established mechanisms to enable discovery of
providers associated with this ‘trust community’ in the nations first
Federated Provider Directory.
• At the end of the grant, we asked ourselves if we should continue to
support the programs we had started.
• I think the best way to sum up the conclusion of the members at the
time was the image that was conjured up when we asked ourselves
“What if the State’s didn’t Collaborate on establishing HIE?”
9
Incorporation
 Independent non-profit organization established in Washington DC, May 2013
 Bylaws, governance body, and organizational structure developed
 Vision: HIE Governance is the path to trusted exchange
 Mission: Initiate and/or participate in the development of national standards
that support ongoing HIE
 State Level Membership
 Member States: Alaska, Arkansas, California, Colorado, Florida, Hawaii,
Michigan, Nevada, North Dakota, Oregon and Utah
 Interested States: Arizona, Georgia, Idaho, New Mexico, Washington and Ohio
 Current Funding Streams
 Member State’s Pay population based annual fee
 Grant awards
 In-kind participation and volunteer activities
Nation’s First Trust Bundle for DIRECT
Each state knows how to
query each other state.
Complexity within a state is hidden.
Nation’s First multi-state
Federated Provider Directory Pilots
State HISP
AK State Directory
State HISP
CA State Directory
Regional HISP
OR State Directory
Regional HISP
Regional HISP
Completed Phase 1 PHR related Pilot
Provider
HISP
Current
Bundle
Provider
HISP
New Bundle:
Provider-to-consumer exchange
Directenabled
PHR
New Bundle:
Consumer-to-provider exchange
NATE’s current activities at 1 years old
• Legal Barriers: The Model Modular Participants
Agreement and OLHIE
• Policy Barriers: Trust framework for bidirectional
exchange between patients and providers; as well
as initial real world piloting of SAMHSA’s
Consent2Share software for HIE
• Technical Barriers: Leadership roles related to
the OHT CONNECT Community and
participating roles in relation to NSTIC pilots;
Addressing Legal Barriers
Model Modular Participants Agreement
• During my tenure in California one of the tools
that we developed, which is migrating to the open
source environment I will be describing in a
moment, is the Model Modular Participants
Agreement
• I understand that Legal Agreements are a hot
topic of discussion here in Pennsylvania so I
thought I would talk a little bit about what we
developed and then tell you what we are doing to
make it more readily available
What is a Participants Agreements?
• What are Participant Agreements and why are they
important to the eHealth Vision?
• Participants Agreement – the contract between an HIO
and its Participants, the purchaser of the HIOs service
offerings.
• Participants Agreements describe the obligations of
both parties and are essential to describing the rules of
the road.
• Since the service offerings of each HIO is different and
how those service offerings are delivered differ there is
no one size fits all contract that can be proposed.
18
Frequently cited as a barrier to exchange
• Pain Point –Why?
• For emerging HIOs these contracts are costly to
develop and finalize
• For Participants the variance between Agreements
increases the difficulty in evaluating them and
ultimately executing them.
• Significant elapsed time lost to legal review
When I was at CalOHII we heard from all types of Stakeholders that the participant’s agreement
was an area where the community could benefit from a tool – perhaps a Model Participants
Agreement?
19
But why is this so hard?
• If you have seen one HIO, you’ve seen one HIO
• There are many mechanisms to enable appropriate
health information exchange
• Many HIOs offer multiple mechanisms to enable health
information exchange depending on the use case and
customer needs
• These compounded differences and the complexity of
the learning curve makes it difficult for any single
organization to support the resource requirements to
readily master all of the details.
• To produce results our task force had to make some
simplifying assumptions…
20
All models are wrong and
only some are useful.
~ D. Edwards Deming
21
HIOs support many different modes of exchange
• The Task Force recognized that there are many
methods of exchange being offered today
• Ranging from a Conduit offering all the way to
Offerings that provide Patient Centric Longitudinal
Views made up of data from many Participants
• Yet, the Pareto rule does apply and many terms and
conditions are common regardless of the mode(s) of
exchange being considered
…yet many of the principles are the same –
such as ensuring security and preserving
privacy.
Give me a
fruitful error anytime, full
of seeds, bursting with its
own corrections.
~ Vilfredo Pareto
23
Iterative Development
• MMPA Release 1.1
• Formed Task Force in July 2012
• Drafted straw-man and iterated numerous times
• 30 day comment period ; input incorporated
• Presented Candidate version to CalOHII
• Released by CalOHII in September 2012
• MMPA Release 2.0
• Following same pattern of development
• Incorporated updates result of Omnibus Rule
• Formally released by CalOHII in August 2013
• MMPA Release 2.2.1
• Addendum with corresponding DURSA provisions for ease of
incorporation by HIOs using the MMPA as part of multi-party
trust agreement.
MMPA R2 Task Group Members Included
Allen Briskin (Co-Chair)
Pillsbury, Winthrop, Shaw, Pittman, LLP
Jana Aagaard
Of Counsel to Dignity Health
Law Office of Jana Aagaard
Sergio Bautista
CFO\COO
Community Health Alliance of Pasadena
Paul Budilo
Executive Director
OCPRHIO
Martin Love
Chief Executive Officer
North Coast Health Information Network
John R. Christiansen
Christiansen IT Law
James Killeen, MD
University of San Diego
Dept. of Emergency Medicine
Cassie McTaggart
Cal OHII Division Chief
Health Information and Policy Standards
Austin O’Flynn (Co-chair)
Senior Counsel, Dignity Health
Alice Leiter
Policy Counsel,
Center for Democracy and Technology
Bill Beighe
Chief Information Officer
Santa Cruz Health Information Exchange
Richard Swafford, PhD
Executive Director
Inland Empire Health Information Exchange
Michael Smith
Director of Operations
HealthShare Bay Area
Dr. Lisa Scott
Deputy Compliance Officer
Sacramento County
Hugo Von Bernath
Healthcare Information Resource Center
Office of Statewide Health Planning and
Development (OSHPD)
Kerry Cataline
Cal OHII Branch Chief
Health Information and Policy Standards
Intended use
• The MMPA is a tool to aid you. It does not eliminate the need to work with legal
counsel.
• For those of you who are currently developing Participants Agreements we hope
this is helpful in accelerating the process.
• For those of you who are potential Participants, we hope this tool helps you
evaluate the agreements of HIOs you’re working with.
• As we move toward enabling inter-HIO exchange we hope that the MMPA
facilitates the process of verifying alignment of any HIO’s Terms and Conditions
to this common baseline in order to minimize the need for point-to-point
agreements between HIOs.
• The theory is that having a reference point we can Index Participants Agreements
and ultimately simplify the comparison of terms and conditions and enable the
acceleration of HIE Adoption at the participant level and across HIOs.
26
80/20 Rule – Common Sections
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Section 1 - INTRODUCTORY AND GENERAL PROVISIONS
Section 2 - DEVELOPMENT AND ADMINISTRATION OF PARTICIPATION AGREEMENTS
Section 3 - TERM AND TERMINATION OF PARTICIPATION AGREEMENTS
Section 4 - AUTHORIZED USERS
Section 5 - GENERAL OBLIGATIONS OF PARTICIPANTS
Section 6 - DATA RECIPIENT’S USE OF SYSTEM AND SERVICES
Section 7 - DATA PROVIDERS’ USE OF SYSTEM AND SERVICES
Section 8 - ASSOCIATED HARDWARE AND SOFTWARE TO BE PROVIDED BY HIO
Section 9 - PRIVACY AND SECURITY OF PATIENT DATA
Section 10 - BUSINESS ASSOCIATE AGREEMENT
Section 11 - HIO’S OPERATIONS AND RESPONSIBILITIES
Section 12 - GOVERNANCE
Section 13 - FEES AND CHARGES
Section 14 - PROPRIETARY AND CONFIDENTIAL INFORMATION
Section 15 - DISCLAIMERS, EXCLUSIONS OF WARRANTIES, LIMITATIONS OF LIABILITY, AND
INDEMNIFICATION
Section 16 - INSURANCE AND INDEMNIFICATION
Section 17 - TRANSPARENCY, OVERSIGHT, ENFORCEMENT AND ACCOUNTABILITY
Section 18 - MISCELLANEOUS PROVISIONS
Exhibit X – Business Associates Agreement
Using the MMPA
• The MMPA is a starting point.
• Take from it what you can and leave what you can’t.
• We have tried to identify the key sections that should be
considered and suggested alternative language that may
inform development of specific language for your
Organization.
• Your specific situation may require more sections or
fewer depending on your specific offerings and
relationships.
• If the MMPA improves the community’s ability to
communicate about these agreements it will have been
a success.
28
What does Modular mean? Several things…
• Given the spectrum represented by the different modes of exchange
we would tend to expect that those modes on the higher end of the
spectrum would have more Terms and Conditions relative to those on
the lower end of the spectrum.
• So the current framework attempts to be incremental in that it
includes sections that may be unnecessary for some modes of
exchange while for others it may be incomplete and additional terms
and conditions specific to the HIO are warranted.
• By including the word modular we intended to connote a vision of
future releases of the MMPA with separate modules specific to
service offerings or capabilities of HIOs that are currently undefined
or still emergent.
• We also expect the modular aspect of the MMPA to increase in the
future as additional Participant Types are considered (Patients,
Secondary Use, others)
29
Model Modular Participants Agreement
• What is it for?
• It is a reference point for HIOs that can be leveraged to
draft or update existing Participant’s Agreements; and
• A reference point for Participants use when they are
presented with an agreement by an HIO; ultimately
• It is a starting point to build from with your inputs
• What is it not?
• It is not a replacement for your own legal counsel nor
is it to be construed as legal advice.
It is a good example of the kinds of assets you should be able to find in OHLIE.
Addressing Legal Barriers
The Open Library of HIE (OLHIE)
• OLHIE was a project originally funded by the
ONC fostered leveraging Open Health Tools open
source community processes
• OLHIE is a repository of reusable HIE Assets
such as interfaces, adaptors, use cases, tool-kits,
policy artifacts and model contract language
• OLHIE is currently migrating to live under
NATE’s wing and will soon be the home of the
MMPA among similar assets.
The Open Library of HIE (OLHIE)
• Streamline onboarding with NATE members
• Serve as a common ground for States and Vendors to
share assets and communicate ideas
• Encourage contribution from the private sector
• Provide community oriented, outward facing location
to store and retrieve assets generated by NATE
members and other HIT projects
• Allow the community to vet and promote reusable
assets, moving towards common practices
• Encourage vendor transparency and good stewardship
of the marketplace
Addressing Legal Barriers
The Open Library of HIE (OLHIE)
• To learn more about OLHIE please visit –
www.OHLIE.org
• Or get in touch with NATE’s VP of Operations
[email protected]
To get the latest information related to the MMPA please visit:
http://www.ohii.ca.gov/calohi/content.aspx?id=143
Addressing Policy Barriers
Consent2Share
Emerged from ONC’s Data Segmentation for Privacy (DS4P) Initiative
VA-SAMHSA DS4P Pilot
Consent2Share
The ONC DS4P Initiative was launched in October 2011 to demonstrate,
through pilot initiatives, the vision outlined by the December 2010 PCAST
report on Health IT. Out of that report came the recommendation for the
development of metadata tags which could be used to maintain privacy and
security of patient health information throughout data exchange across
organizational structures. It also advised that patients and providers be able to
share portions, or segments, of records in order to maintain patient privacy.
DS4P Achievements:
• DS4P Implementation Guide
• Pilot projects including VA-SAMHSA DS4P Pilot and this project
http://wiki.siframework.org/Data+Segmentation
Initiative Coordinator: Johnathan Coleman
Addressing Policy Barriers
Consent2Share
ONC Data Segmentation for Privacy (DS4P) Initiative
VA-SAMHSA DS4P Pilot
Consent2Share
One of the ONC DS4P pilot projects, the VA-SAMHSA DS4P
Pilot, was a partnership between the Department of Veteran’s
Affairs and SAMHSA which demonstrated, through a prototype
implementation, the standards established in the DS4P
Implementation Guide. The VA-SAMHSA DS4P Pilot prototype
was demonstrated in September 2012 at HL7 and in the
Interoperability Showcase at the March 2013 Annual HIMSS
Conference.
http://wiki.siframework.org/DS4P+VA-SAMHSA+Pilot
Addressing Policy Barriers
Consent2Share
ONC Data Segmentation for Privacy (DS4P) Initiative
VA-SAMHSA DS4P Pilot
Consent2Share
Building on the components and learnings from the VA-SAMHSA DS4P
pilot, Consent2Share is being built as a production-grade system capable of
implementing consent management, data segmentation and privacy
enforcement in live environment.
Consent2Share consists of two application area: Patient Consent
Management and Access Control Services. C2S Patient Consent Management
system is a patient-facing Consent Management User Interface which allows
patients to define their privacy policy and provide informed consent. The
C2S Access Control Service components are designed to integrate with
Electronic Health Records systems (EHRs) and HIEs and provide privacy
policy configuration, management, decision making and policy enforcement.
The project is open source and source code is available at:
https://github.com/OBHITA/Consent2Share
Consent2Share Project Goal:
Project Goal: Provide the capability for patients receiving behavioral health
treatment to share their health information through the nation’s HIEs while
providing meaningful choices for protection of their privacy
Objectives of the Pilot:
•
Demonstrate the sharing of health records from a substance abuse treatment provider to a
Primary Care using the Consent2Share toolset via local HIO
•
Demonstrate the application of patient privacy preferences with granular data segmentation
options to patient medical records, through the standards developed by the ONC DS4P
initiative
•
Demonstrate that patients can understand and manage their privacy preferences through
Consent2Share
•
Evaluate patient and provider response to and acceptance of the Consent2Share tool
•
Evaluate how the Consent2Share tool can be implemented into the workflow of the
provider organizations and the HIE while ensuring compliance with the broad requirements
of 42 CFR Part 2 and applicable state laws, including restricting redisclosure of protected
information
Addressing Policy Barriers
Consent2Share
Consent2Share components:
•
Patient Consent Management – Patients enter their privacy
preferences and provide consent. (front-end, patient facing)
•
Access Control Services – Integrates with HIE and enforces access to
records and privacy policies. (back end control system)
Addressing Policy Barriers
Consent2Share
Patient Consent Management
• Consent2Share Patient Consent Management
• Patient-facing Consent Management User Interface which allows patients to
provide informed consent and specify a privacy policy.
• Web-based, Responsive UI design allows access across devices (desktop, tablet
and phone)
• Key Features - Patients will be able to:
• Learn about patient privacy options.
• Define which providers they want to share their records with
• Define their privacy policy and sign electronic consent.
• Try their privacy policy against their actual health record. (not yet
complete)
• Receive/Send messages from providers who have, or want to establish, a
sharing connection (not yet complete)
Addressing Policy Barriers
Consent2Share
Access Control Services (ACS)
•
ACS set of integrated applications which are designed to
integrate with EHRs and HIEs and provide privacy policy
configuration, management, decision making and policy
enforcement including data segmentation.
•
•
•
•
•
•
•
Policy Enforcement Point (PEP) Integration point
Policy Decision Point (PDP)
XDS.b Document Registry and Repository
Segmentation Service
Business Rules Management System to support jurisdictional and
organizational privacy policy management
Sensitive data value set terminology management
Integration with HIE MPIs
Addressing Policy Barriers
Technical Overview - Components
Addressing Policy Barriers
Technical Overview – Data Flows
Addressing Policy Barriers
Currently in real world pilot
Addressing Policy Barriers
Consent2Share iterative expansion
Nationwide
Multi-state
Today
State-wide
County
Feel free to contact me if your
interested in learning more or being
part of future iterations with NATE!
Addressing Policy Barriers
CONSUMER-MEDIATED EXCHANGE
• Consumer-mediated exchange provides patients with
access to their health information, allowing them to
manage their health care online in a similar fashion to
how they might manage their finances through online
banking. When in control of their own health
information, patients can actively participate in their
care coordination by:
• Providing other providers with their health information
• Identifying and correcting wrong or missing health
information
• Identifying and correcting incorrect billing information
• Tracking and monitoring their own health
Addressing Policy Barriers
Addressing Policy Barriers
Script 1: Easing the administrative burden on providers
SCHIE Affiliated
Provider
Patient (NMC)
SD Health Connect
Affiliated Provider
NATE Members
SCHIE, SD Health Connect and NoMoreClipboard
While visiting Santa Cruz patient
Olive Trekker receives care from
Dr. Earl Grey at Santa Cruz
Hospital.
Dr. Grey pushes
encounter data to
Olive’s NMC account.
Direct Message
Olive accesses her data via the NMC patient portal.
Olive then pushes data to her San Diego provider,
Nurse Chris Care, via SD Health Connect.
Direct Message
Nurse Chris Care receives
Olive’s encounter data.
47
Addressing Policy Barriers
Script 2: Wireless science leveraging micro and macro environmental data
Direct
Message
Dr. Killeen receives
comprehensive view of
Gloria’s exposure and
inhaler use.
Direct Message
Gloria’s HealthVault account
is updated. Gloria pushes
data to Dr. Killeen.
HealthVault
SD Health Connect
Affiliated
Provider
Asthmatic patient Gloria Gilliam receives care
from Dr. James Killeen at UCSD Medical
Center. Dr. Killeen provides her with two
asthma sensors.
Gloria’s HealthVault
account is updated
following final visit.
San Diego
Health Connect
Microsoft Azure Cloud
Direct Message
Macro Air
Quality
Data
(Delphi)
Azure Cloud integrates Gloria’s device data and
macro environmental data from the Delphi Project.
Aggregate data sent to Gloria’s HealthVault account.
MS Proprietary Data Transfer
(Not Direct Message)
Patient
NATE Members
UCSD Health System, CitiSense, Propeller Health, HealthVault, SD Health Connect, Delphi
Gloria receives and
uses her CitiSense
sensor and Propeller
Health sensor.
Device Data
Transmitted to
Mobile Phone
(via Bluetooth)
Gloria sends sensor data
from her mobile phone to SD
Health Connect in Microsoft
Azure Cloud.
Addressing Policy Barriers
Script 3: Ensuring patient safety with mobile anytime/anywhere access to health records
SD Health Connect
Affiliated Provider
Dr. Killeen transmits
UCSD Epic C-CDA to
Vet’s Humetrix
iBlueButton app.
Vet receives care from
Dr. Killeen at UCSD
Medical Center.
Pre-Populated Data
Humetrix iBlueButton
Smartphone App
Direct Message
SCHIE Affiliated
Provider
NATE Members
San Diego Health Connect and Humetrix iBlueButton
MyHealtheVet
CCD
Medicare BB
Record
TriCare Online
CCD
Direct
Message
Data Pulled
Direct
Message
The iBlueButton app provides an
aggregated view of all data and
enables the patient to annotate his
records.
Device to Device
Secure Transfer
OR Visual Sharing
Dr. Smith has access to
Vet’s current medical
history when Vet
receives care from Dr.
Smith in SC.
iBlueButton App is
updated by receiving CCDA from Dr. Smith.
Direct Message
Dr. Smith transmits CCDA to Vet’s Humetrix
iBlueButton app.
Addressing Policy Barriers
NATE’s Phase 2 PHR Call for Participation
Read the ONC Buzz Blog
http://nate-trust.org/phr-community-signup/
Addressing Technical Barriers
NATE Providing Leadership
User Advisory Group, Co-Chair – Dr. Rim Cothren (NATE’s CTO)
Project Management Council, Project Lead – Aaron Seib (NATE’s CEO)
Interested in getting involved? Want to register to keep informed? Go to:
http://www.openhealthtools.org/connect-project-information/
Addressing Technical Barriers
Identity Proofing at Scale - CSDII Consortium
Private and public sector Individuals, Relying Parties, Identity
Providers, Identity Proofers, Attribute Verifiers, Attribute Providers,
Credential Service Providers, and Privacy Enhancing Technology
Providers to include:
Architecture
Relying Party
PETP
IdP:
Commercially
Available
AV: Attribute
Verification
User Services
Business Requirements
Trust Framework Policy Enforcement
Claim Consolidation
CSP
Biometric
(Something you are)
CSP
Device
(Something you have)
IdP:
COI Specific
AP: Attribute
Provider
CSP
KBA
(Something you know)
SELF-ASSERTED
STRONG
STRONGER
Attribute / Credential
Authentication & Verification
Identity Proofing
Consolidated
Claim Set
Stronger Credential
Stronger Authentication
Strong Authentication
Evolve Trust Framework & UX
Use Cases
• Patient Access to
Electronic Health Record
•
Social IDP
Verified Attributes (for
patient matching)
Two Factor
Authentication
• Provider Access to Health
System
•
•
Strong identity proofed
Credential
Multi-Factor
Authentication
Patient
OAuth
•
•
CSDII
Provider
Health Care System
EHR Login
EHR Web Application
EHR Core
Stay Tuned
• Pilot Launch in May (Period of Performance: 6 months)
•
•
Patient Access Use Case
Provider Access Use Case
• Solutions to enable stronger identity proofing are on
their way!!!
Recap – to learn more or get involved!
Legal Barriers
• To learn more about the MMPA and OLHIE please contact:
[email protected]
Policy Barriers
• To learn more about Consent2Share please contact:
[email protected]
• Patient Mediated Exchange
http://nate-trust.org/phr-community-signup/
Technology Barriers
• CONNECT: Open Source Community
http://www.openhealthtools.org/connect-project-information/
• CDSII
• [email protected]
How do you make the Universe Laugh?
How do you make the Universe Laugh?
Tell it your plans.
But one thing is for sure
- if it helps our families in the future –
its all worth it to me.
Community Discussion
61
Backup
Trust Communities & Trust Bundles
1) Prospective members
such as HISPs and PHRs
must fulfill Trust
Community
requirements to join.
HISP
Federated Trust Agreement
Certification/Accreditation
Trust Organization
Trust Profiles
Trust Organization
2) As new members are
approved by the
Community, they supply
their trust anchors to
the Trust Organization.
3) Based on new
members’ conformance
to the Community’s
Trust Profiles, the Trust
Organization adds their
trust anchors to one or
more Trust Bundles.
HISP
Trust Organization
Trust
Bundle
63
Trust Communities & Trust Bundles
Trust Organization
4) Trust Organization publishes Trust
Bundles to Community web server.
5) Community members pull down Trust
Bundles periodically at regular intervals.
HISP A
HISP B
HISP C
6) A particular Trust Bundle contains the
trust anchors of all the members of the
Community that conform to a specific
Trust Profile. By configuring their Direct
Security/Trust Agents (STAs) to trust the
anchors in a Bundle, Community
members can successfully communicate
with all other members within that
Bundle.
64
Five modes of exchange;
One Modular Model Participant’s Agreement
Exchange Model #1
Conduit
• The HIO provides for the
transport of messages only.
• Each Participant in the
Exchange independently
encrypts the PHI
• HIO does not have access to
Participant’s Private Key
65
Five modes of exchange;
One Modular Model Participant’s Agreement
Exchange Model #2
Model 1 + HIO has access to PHI
• The HIO provides for the
transport of messages; and
• The HIO provides for the
encryption of PHI and thus
has access to unencrypted
PHI; but
• Does not modify nor retain
data.
66
Five modes of exchange;
One model Participant’s Agreement
Exchange Model #3
Model 2 + HIO transforms data but
does not retain
• The HIO provides for the
transport of messages; and
• The HIO provides for the
encryption of PHI; and
• HIO has access to unencrypted
PHI; and
• Modifies it but does not retain
data.
67
Five modes of exchange;
One Modular Model Participant’s Agreement
Exchange Model #4
Model 3 + the HIO retains data to
provide other services
• The HIO provides for the
transport of messages; and
• The HIO provides for the
encryption of PHI; and
• HIO has access to unencrypted
PHI; and
• Retains the PHI to provide other
services such as patient matching
68
Five modes of exchange;
One Modular Model Participant’s Agreement
Exchange Model #5
Model 4 + the HIO performs analysis
related to clinical data
 The HIO provides for the
transport of messages; and
 provides for the encryption of
PHI; and
 has access to unencrypted PHI;
and
 Retains the PHI to provide other
services; and
 Performs additional analysis to
inform clinical decision making.
69