direct scalable trust forum

Direct Scalable Trust Forum

November 29 – November 30, 2012

Welcome

Farzad Mostashari

Putting “Scalable Trust without Governance” in Context

Claudia Williams

What Issues are We Trying to Solve?

• Current Direct deployments are “islands of exchange” limited to single HISPs or supported by HISP to HISP business agreements

• What’s the problem? Don’t know which HISPs to trust

• This is an urgent issue as the current deployment model does not support our goals of ubiquitous directed exchange to meet stage two of meaningful use

• Common expectations about user authentication, types of certificates to be used and mechanisms for sharing trust bundles/white lists will support scalable trust

• Trust communities have emerged to address these issues, urge adoption of solutions across participants and avoid the need for peer to peer agreements

• If these trust communities place different requirements on HISPs, healthcare providers and/or their patients may still find it difficult to engage in secure, directed health information exchange

Note: Providers and patients will still need ways to establish ad hoc trust. This capability is needed for EHR certification and to support VDT.

- 4 -

Goals for Next Two Days

Enable providers to seamlessly exchange patient information with each other using Direct across vendor and provider boundaries as the field moves into stage 2 of meaningful use.

To reach this goal, the community has agreed to tackle these three issues in the next two days:

1. Identify and encourage adoption of common policies and practices for identity proofing and certificate management that can be adopted across trust communities

2. Make progress on a common technical mechanism for distributing trust anchor bundles within and, to the extent possible, between trust communities, that will be piloted in the next 2-3 months

3. Identify other common business practices or requirements that will reduce the need for or simplify trust agreements between HISPs

- 5 -

Principles

• Supports ubiquitous directed exchange

• Can reach widespread implementation in 6-12 months Feasible with available resources Scalable and easy (enough) to implement

• Keep it simple Minimum necessary and nothing less Don’t let the perfect be the enemy of the good enough Go for 80 percent everyone can agree on

- 6 -

Agenda, Ground Rules, and “What We Mean by Scalable Trust?”

Paul Tuten

Agenda – Day 1

- 8 -

Day 1 – 10/31 9:00 – 5:30 PM ET

9 – 9:15 AM Welcome Farzad Mostashari, National Coordinator

9:15 – 9:30 AM “Scalable Trust” In Context

Agenda and “What Do We Mean By Scalable Trust?”

Claudia Williams, State HIE Program Director

Paul Tuten, ONC Contractor

9:30 – 10:30 AM Overview of Direct-focused Trust Frameworks / Efforts

Representatives from:• DirectTrust• Western States Consortium• NSTIC Pilot (Gorge Health Connect

/ San Diego Beacon)

10:30 – 10:45 AM BREAK

10:45 – 12:15 PM HISP Privacy & Security Safeguards / Operating Policies John Feikema, S&I Framework CoordinatorPaul Tuten, ONC Contractor

12:15 – 1:30 PM BREAK FOR LUNCH

1:30 – 3:30 PM Identity Verification and Certificate Issuance John Hall, Direct Project CoordinatorDebbie Bucci, Security Advisor

3:30 – 3:45 PM BREAK

3:45 – 5:15 PM Trust Anchor Distribution Mechanisms John Hall, Direct Project CoordinatorPaul Tuten, ONC Contractor

5:15 – 5:30 PM Closing Remarks Paul Tuten, ONC Contractor

Ground Rules

• We’re NOT re-litigating the Direct specification

• Single certificate to be used for signing and encrypting in the transport of data

• Address-bound and domain-bound certificates are equally valid

• We’re NOT re-litigating architectures / deployment models for Direct

• Locally or remotely hosted STAs (and any associated infrastructure) are equally valid

• Provider or 3rd party managed STAs (and any associated infrastructure) are equally valid

- 9 -

Ground Rules

• We ARE building from the policy guidance released by ONC for use by State Health Information Exchange grantees

• Acknowledging areas of broad consensus between Direct ecosystem participants

• Focusing conversation / energy on areas where consensus has not yet formed

• We ARE attempting to understand how to best enable end-users to engage in directed information exchange

• This implies striking an appropriate balance between ease of use in enabling exchange (i.e., “establishing trust”) and ensuring adequate privacy and security safeguards

• Other transport mechanisms will be used by providers and vendors to

support diverse health information exchange use cases and needs. This meeting will focus on the specific opportunities and challenges around creating scalable trust for Direct

- 10 -

Ground Rules: And Finally…

• Presume good intentions

• Help group stick to meeting goals and principles

• If you raise a problem, propose a solution

• Have fun!

- 11 -

Parking Lot Issues

• Given time constraints, we may need to place issues in a parking lot for later consideration

• Tomorrow, our agenda is an “Open Space” meeting in which we intend to address some (if not all) of these issues

• Likewise, please feel to contribute topic suggestions for tomorrow’s Open Space meeting throughout the day

- 12 -

To Quickly Capture Feedback…

• From time to time, facilitators may ask the group to demonstrate their support for certain ideas, concepts, or proposals

• We’re using a very high-tech system of… flash cards:

• Green/Circle = Strong support / preferred option

• Yellow/Triangle = Willing to support / acceptable option

• Red/Square = Absolutely cannot support / not a viable option

• Please hold them up high (so we can see them)

• And, remember to bring them back tomorrow…

- 13 -

What is Scalable Trust?

An efficient means of enabling Direct exchange between participants on disparate HISPs. Fundamentally, it is predicated on two things:

• Common trust frameworks / policies

• Technical mechanisms to automate trust between framework participants

- 14 -

Scalable Trust in “Three Easy Steps”

1. Trust Umbrella Organization defines requirements for participation

2. Trust Umbrella Organization enrolls/accredits/certifies entities to be included in an Trust Anchor Bundle

3. Trust Umbrella Organization enables mechanism for electronic distribution of Trust Anchor Bundle to all members

- 15 -

Example of Scalable Trust Model

Trust Organization

HISP BHISP AProvider A

Provider B

Centralized Trust Anchor Bundle Store

- 16 -

Example of Scalable Trust Model: New HISP Joins Trust Organization

HISP BHISP AProvider A

Provider B


HISP CProvider C

- 17 -

Trust Organization

Example of Scalable Trust Model: Peer-to-Peer Reciprocity

Trust Organization A

HISP BHISP A


Trust Organization B

HISP DHISP C


- 18 -

This is the aim of this meeting: working toward sufficient alignment—while allowing for differences—to enable widespread interoperability

Overview of Direct-focused Trust Frameworks / Efforts

David Kibbe – DirectTrustAaron Seib – Western States ConsortiumBrian Ahier – NSTIC Pilot

DirectTrust

Direct Scalable Trust ForumNovember 29, 2012

David C. Kibbe, MD MBAPresident and CEO

04/11/2023 20

DirectTrust• Non-profit, competitively neutral, self-regulatory entity created by and for

Direct community participants.

• Establishing and maintaining a national Security and Trust Framework (the “Trust Framework”) in support of Directed exchange.– A set of technical, legal, and business standards for Directed exchange– Expressed as policies and best practices recommendations, which members of

DirectTrust agree to follow, uphold, and enforce.

• Leveraging the Trust Framework for a Direct Trusted Agent Accreditation Program, DTAAP, with EHNAC, for HISPs, CAs, and RAs, as well as their clients.

• Complementary and subject to, as well as supportive of, the governance rules, regulations, and best practices for the Direct Project and the NwHIN, promulgated by HHS and ONC, and the mandates of the HITECH act.

04/11/2023 21

Current Members*

• American Academy of Family Physicians

• Cerner Corporation• DigiCert• EHNAC• Gemalto• Gorge Health Connect• HealthcareXchange• HealthShare Montana• Healthwise • Informatics Corp of America• Lexis Nexis• MaxMD

• McKesson Corporation• MedAllies• Medicity• Morrell Taggard, Inc.• Ohio Health Info Partnership• Nitor Group• Redwood Mednet• Rhode Island Quality Institute• SAFE Bio Pharma Assoc.• State of Tennessee• Surescripts• Techsant Technologies• Walgreens

* DirectTrust.org had over 200 members of its wiki when the transition to aMembership model of organization began in October, 2012.04/11/2023 22

Membership Eligibility – A Big Tent• DirectTrust membership is available to:

– Direct exchange participants who are providers or users of Direct exchange services

– Healthcare provider organizations – Organizations providing services to healthcare providers – Government entities – Educational or scientific research organizations– Any other nongovernmental entity serving the healthcare industry with an

interest in Direct exchange and the NwHIN.

• Annual membership dues for an organization are between $250 and $10,000 and based on the organization’s annual revenues related to health-care business.

04/11/2023 23

DirectTrustDirect Project Rules of the Road workgro

up formed

April 2011

DirectTrust.org wiki

established

December 2012

DirectTrust.org

incorporated

April 2012

"A Trust Framework is a set of technical, business, and legal standards, expressed as policies and best practice

recommendations, that members of a trust community agree to follow, uphold, and enforce."

04/11/2023 24

DirectTrustX.509 Certificate Policy Established Dec. 2011

Testing and Recognition

ProgramSept. 2012

Accreditation ProgramFeb. 2013

Trusted

Anchor

Bundle

Distributio

n Servi

ceMarc

h 2013

”Within the context of Directed exchange, Trust Agents includeHealth Information Service Providers, HISPs, Certificate Authorities,

CAs, and Registration Authorities, RA s”

04/11/2023 25

04/11/2023 26

04/11/2023 27

Direct Trusted Agent Accreditation Program, DTAAP

04/11/2023 28

Direct Trusted Agent Accreditation Program, DTAAPExample Criteria from Section II

Strategic Context

• Common need for assurance around security, trust, and identity as a pre-condition for health information exchanges on the Internet.

• Development of a new paradigm for identity management that shifts identity management responsibilities to an authoritative and trusted identity management network that acts as an ecosystem for identity.

• A new role within that ecosystem for Trust Framework providers, who are responsible for ensuring that the identity providers meet agreed-upon standards for issuing identity credentials and sharing appropriate information, thereby allowing the relying parties to confidently accept and use the credentials.

• DirectTrust members recognize Internet sharing of health information requires the establishment of a Trust Framework suitable to the needs of providers and patients has to occur, and that it will need to grow and evolve over the next few years.

The Direct Project. Blue Button Initiative. EPCS. NSTIC. Stage 2 Meaningful Use objectives for Care Coordination and Patient Engagement. ACOs. RHEx.

04/11/2023 29

Workgroups

Security and Trust

Compliance

Citizen and Patient

Participation

Certificate Policy and Practices

04/11/2023 30

Security and Trust Compliance Workgroup

Chair Andy Heeren, Cerner Corporation

Purpose Create a program which can be used by HISPs to voluntarily apply, qualify, and thereby be able to attest, to having met or exceeded best practices for security and trust, all within the context of and abiding by the policies and regulations as promulgated by ONC and HHS for Direct exchange, and respectful of state laws pertaining to privacy and security that may apply.

Completed • Draft HISP Evaluation Criteria• Draft RA Identity Verification Checklist• HISP/CA/RA Self-attestation Checklist (Security and Trust Specs. Doc)

Active • “Pilot” Trust Community Program Development• Self-Attestation Checklist Review – Round 1 Submission Discussions

Upcoming • Accreditation Program Development

04/11/2023 31

Certificate Practices and Policy Workgroup

Chair Don Jorgenson, InprivaScott Rea, DigiCert

Purpose Establish and maintain a Certificate Policy (CP) and related policy/practices specifications and documentation that will serve as a guide to Health Information Service Providers (HISPs) and their Certificate Authorities (CAs) as they implement Direct exchange programs and services.

Completed • DirectTrust.org Ecosystem Community X.509 Certificate Policy - Draft for Trial Use complete

Active • DirectTrust CP 1.0—Updated and extended from DTU• Scoping out Attestation/Accreditation processes• Identity Proofing Guidance including FBCA Antecedent Proofing• Preparing identity proofing guidelines for Federal PKI Policy Authority Review (FBCA).

Upcoming • So You Want to be a HISP? • Guidance via Frequently Asked Questions

04/11/2023 32

Citizen and Patient Participation Workgroup

Chair Leslie Kelly-Hall, HealthWise

Purpose Encourage and enable broad Directed exchange between citizens/consumers/patients and health care professional through reaching consensus on a shared set of security and trust policies and best practices that will reduce the administrative burden to provision citizens/consumers/patients with trusted identity credentials, including X.509 digital certificates required of participants in Direct.

Completed

Active • Consumer Use Cases• DirectTrust White Paper: Citizen and Patient Participation in Direct - Closing the Gaps• Direct Rules of the Road WG Citizen Community Draft Policy Statement

Upcoming • So You Want to be a HISP? • Guidance via Frequently Asked Questions

04/11/2023 33

Products and Services• Testing and Recognition Program

– Launched in September 2012 with six HISPs/CAs/RAs– Participants submit self-attestations based on DirectTrust’s Security and Trust

Specifications v0.7, which are evaluated for compliance.– DirectTrust will identify those organizations that passed the evaluation on the

DirectTrust.org website, and will distribute a trust bundle to the participants.– Additional rounds are scheduled to be completed during Q4 2012.

• Accreditation Program– Scheduled to launch in Q1 2013– Formal accreditation program for HISPs, CAs, and RAs based on the criteria

established through the Testing and Recognition Program– To be developed and administered in partnership with the Electronic

Healthcare Network Accreditation Commission (EHNAC)

04/11/2023 34

Western States Consortium

November 29, 2012Scaling Trust Briefing

Agenda

State Health Policy Consortium An ONC support grant to get the WSC started Grant Deliverables

Executing WSC – Pilot Scenarios Formation of a Multi-state Governance Body Pilot Scenario’s 1 & 2

Intersections between Governance of Trust Communities and Accreditation Improving Trustworthiness Enabling Local Policy Decisions

Origins at a glance ONC’s State Health Policy Consortium (SHPC) provided grant

funding to evaluate the policy and subsequently pilot the use of digital certificates and provider directories to enable inter-state exchange.

Project received final approval from ONC on November 1, 2011 Grant provided for logistical support (RTI)and limited funds for

contractors that work on the initiative (John Hall, C3 Consulting and Dragon) along with the participants from each of the states

States involved in grant application included OR, CA, NV, AZ, HA, UT, AK, NM.

Known as core states – each of these states have actively collaborated to develop the grant’s work plan & participated in the execution of that plan.

Subsequent to kick-off observing satellite states have included WA, CO, ID, GA & FL. Just last week MI became the latest state to become a satellite participant with the WSC.

Grant deliverable is a “Final” report but the intent from the beginning has been to see the WSC persist as a method of improving trustworthiness of exchange.

Focus of Grant

Approved Work Plan focuses on the practical and technical barriers to ensuring the privacy and security of interstate exchange, with a specific focus on how provider directories and trust services originating in different states can be harnessed and potentially combined at the regional level to promote privacy and security and facilitate interstate exchange using Direct secure messaging.

Overall Objectives

Policy: The key barrier being examined by this work is to evaluate the Policy variances among exchanging states and identify solutions that would enable the exchange of health information

Alternatives analysis and selection: Key elements to be considered included federated provider directory concepts and establishment of trust anchors. How can we implement Trust Bundles and other related processes so that a Certificate from OR can be trusted to assure Identity of a Provider for a caregiver in CA in a consistent policy environment? How can provider directories be used to facilitate trust?

Pilot Implementation: Using a collaboratively established best of breed approach implement a local solution between CA (NCHIN) and OR (CareAccord). Operate pilot and produce report for ONC to distribute to nation.

Work plan – Tasks

Task 1: Status Meetings with RTI Task 2: Research, Preparation, and Analysis Task 3: Trust Services & Provider Directory

Services Task 4: Weigh Options and Determine Solutions Task 5: Preparation to Implement Solutions Task 6: Steps Toward Implementation Task 7: Execute Pilot Scenarios Task 8: Produce Report Post SHPC

41

ExecutingWSC – Pilot Scenarios

• Formation of a Multi-state Governance Body• Pilot Scenario’s 1 & 2 and beyond

42

Pilot Landscape

43

WSC-MOU; Relationships; Policies and Procedures

44

Key initialization milestones

Execution of MOU by OR & CA – establish Governance Body

Governance Body approved initial Policies and Procedures Policy & Procedure Change Process Onboarding WSC-Qualified Entities Communications Policy

CA executed Onboarding P&P for NCHIN OR executed Onboarding P&P for CareAccord November 1 – Test message exchanged between

CA Participant of NCHIN and an OR Participant of CareAccord

45

Test Message sent November 1, 2012

46

Western States Consortium Pilot Scenarios

Use Case: Directed messaging of clinical information

between providers across state lines for

treatment purposes.

WSC is piloting… Policies and Procedures

Governing Body that creates policies, procedures, etc. Defined responsibilities for each Party State. Policies/procedures for Change Control, Eligibility,

Communications, etc.

Technology Trust Bundle that defines a scalable, multi-party Trust

Community. Federated Directory Services that support individual and

organizational endpoint/address discovery.

Scenario 1 and Scenario 2.a & 2.b

Within the Trust Community of the WSC-Pilot:

Scenario 1:Executed the independent evaluation of each state’s respective Pilot-HISP for compliance with common Eligibility Criteria as defined by the Governance Body. Employed shared trust bundle methodology to make Qualified HISPs discoverable to one another. (Live November 1)Scenario 2.a:Implementing address discovery using open-standards based query of HISP’s directories across state lines. The query standard we are currently working with is based on HPDPlus and related S&I Framework Activities. (December 6)Scenario 2.b:Extends Scenario 2.a by introducing a CA services to act as a scalable hub to many HISPs in CA. California will be the first to implement these methods of federation using statewide orchestration services in pilot mode among HIOs in CA.(Assuming go-decision based on experience of running 2.a ~ Release 1.0 of the California is expected to launch mid-January)

48

Governance of Trust Communities, Accreditation

and Innovation

49

Where does Accreditation and Governance intersect for the WSC? Accreditation has the greatest value for those

Eligibility Criteria that: Are common to many scenarios for a given technology;

and Have uniform methodologies that can be verified

Governance has the greatest value for those Eligibility Criteria that: May vary based on what the technology is used for; or Cannot be readily tested and requires scenario specific

policy controls. The WSC Eligibility Criteria are divided into two

sets aligned with these two cases.

50

51

From State HIE Direct CoP meeting November 19, 2012 – John Hall Presentation

Terms Technical Certification – where a repeatable test can

produce a pass fail value for conformance to a set of common technical standards – tends to be product focused Ex: Conformance to the DIRECT Applicability Statement

Accreditation – where scenario specific evaluation assures conformance to a set of common operational standards (that may rely on certified products) – tends to be service focused Ex: Identity Management Using PKI

Governance – where common operational standards are not mature and interoperable trust is dependent on obligations established in contract or law – tends to be inter-organizationally focused Privacy Preserving Policy requirements in the absence of an

‘accredit-able’ method of satisfying consent requirements

52

Technical Certification and Accreditation contribute to trustworthy Governance Where ‘technical certification’ and Accreditation

are very valuable for those uniform requirements that have mature standards.

Governance is useful to facilitate trust where exchange is dependent on aspects of services that do not have uniformly adopted operational standards and must rely on inter-organizational concurrence to work.

An example to consider is how to approach differentiating between HISP that populate CDRs as part of their service offerings from HISP that don’t from Covered Entities that operate a certified DIRECT component from within their EHR.

53

What is important about a model like the WSC and what does it provide? Decentralization of Program Management permits

Local Autonomy while providing for a pathway to mutual recognition across states Each State retains all Sovereign Authority to regulate or

promote HIE within its state; Distribution of evaluation and monitoring of HIOs to the

entities closest to the effected parties with the authority to provide oversight;

Permits intra-state communities to form under each State’s program to ensure local differences are not overlooked

Permits each State to foster innovation within its programs while providing a means to isolate risks related to the innovations from consensus based rules of the road.

54

Governance and Accreditation – complimentary components for scaling trust & innovationGovernance includes management and enforcement to rules, among other functions, some of which might be covered within an Accreditation Program, but not all. A few explicit governance roles and issues that may be addressed by a Governance entity such as the WSC but not necessarily by an accreditation program include: Changing the Culture – provide tools that facilitate trusted

exchange while fostering innovation Explicit norms regarding expulsion from the community, black

listing, revocation of certain privileges, and even fines or penalties in some jurisdictions.

Mutual promotion of best practices and emerging technical alternatives.

Rules and norms regarding sharing of directory information beyond that which is specified in the Direct standard.

Facilitate the prioritization and advancement of additional of common high value transactions that rely on attributes not verifiable via technical test today.

55

Investor Presentation Q2 2012

Scalable TrustNovember 29, 2012

NSTIC Pilot Project

• Resilient awarded 12 month, $2M grant to pilot innovative solutions for both healthcare and education

• Trust Network will connect nationally recognized leaders for identity, policy and online content

• Goal is to commercialize solutions and capabilities for rapid adoption by public / private sectors

“Making Online Transactions Safer, Faster, and More Private”

&

National Strategy for Trusted Identities in Cyberspace

• Signed by the President in 2011

• Create new Identity Ecosystems to assure security and privacy

• Pilot grants and an adoption requirement for .Gov websites

Goals of the NSTIC Pilot

Healthcare: Patient-Centered Coordination of Care (PCC) Enable trust for sensitive health and education transactions on the Internet

Provide secure, multifactor, on-demand identity proofing and authentication across multiple sectors, at national scale

Implement an identity ecosystem encompassing patients, physicians and staff which facilitates coordinated care through secure, HIPAA-compliant access to:

Electronic referral and transfer of care messaging

Advanced, on-demand decision support service

Commercialize solutions and underlying capabilities, beyond Year 1

Healthcare: Patient-Centered Coordination of Care

Highlights of Pilot• Populations of seasonal agricultural

workers from SD work and received care in Oregon too

• Identity matching and policy enforcement enables coordination

• Enable NwHIN Direct messaging across HIE platforms and state lines

• Novel, cloud-based decision support available to doctors in both states

• On-demand, privacy-preserving authentication and authorization

• Commercialized identity matching, secure messaging & cloud-based decision support can scale rapidly

Pilot Sites & HIE Software:

Decision Support Partners:

Identity & Attribute Providers:

Advisors on Governance / Protocols / Policy: Principal InvestigatorDr. David Hartzband, D.Sc.Chief Technology Officer Resilient Network [email protected]

An “overlay” that makes existing security stronger, and provides unmatched capabilities for cross-enterprise collaboration and commerce.

Achieves security and privacy - anonymous authentication, privilege management and monitoring support identity verification and matching without exposing identity information

Enhances data security because the data is not actually shared; making is safer to use to prove claims

The Trust NetworkResilient Trust Network

Coordination of CareeReferral Messaging

Transfer of Care Messaging

ClinicalDecisionSupport

Powered by:

input

results

input

results

• “Closes the Loop”

• Handles Identities “In the Network”for use of portals and web services

• Resolves policies within and across:• Organizations• Tech platforms• State lines

• Interoperable

CardiologistPrimary Care Physician

&

Identity Syndication

user

Identity BrokerCorrelates, verifiesand authenticates identities of users and records.

1. “I am Dr. John Smith”2. “I am a Cardiologist”

HIE / HISP

LexisNexis

NaviNet AMA

Identity Providers- Commercial ID Providers- Professional associations- Other applications, directories and services

Identity SyndicateAggregates and organizes identity attributes (inputs from ID Broker) and calculates Levels of Certainty

Identity SyndicateYe

s

May

be

1st C

laim

Con

firm

ed

2nd

Cla

im C

onfir

med

Yes

May

be

Yes

Inco

nclu

sive

Verified Identity

Dr. Smith Enabled for Use

PhysicianOffice 2

Trust Enables : Authorized Relationships

PhysicianOffice 1

Establishes Trust Graphs by enforcing the policies that form these relationshipsDr. Smith’s Office

Authorized Relationships

Notification of information requiring authorization

Dr. Brown’s Office Authorized

Relationships

Encrypted exchangecan now occur

Trust Graph 1

TrustGraph 2

Dr. Smith

Patient

Staff Staff

Dr. Brown

Patient

Expansion and Connections to Other Initiatives

DIRECT Projects

Western States Initiative – focus on how state-level provider directories and trust services can be

federated at a regional level to promote privacy and security and facilitate interstate exchange

• Oregon and California will implement a proof of concept pilot that will support the solutions

agreed upon by the group

• Alignment of interests and outcomes creates synergy between projects

Automate Blue Button Initiative (ABBI) – develop standards and specifications that allow patients

to download their health information, and to privately and securely automate sending records to their

preferred holding place.

• Pull Workgroup: allowing a third party application to access personal health data on

demand

• Plans to leverage identity ecosystem from NSTIC

Collaborative and Cloud-based Healthcare Apps/Services

Aetna Strategic Services

• ActiveHealth CareEngine™

• Medicity HIE, and iNEXX Platform

Break

Please meet back in Potomac D&E in 15 minutes!

HISP Privacy & Security Safeguards / Operating Policies

John FeikemaPaul Tuten

Areas of General Consensus w/ State HIE Program Recommendations

• Conform to all of the requirements specified in the Applicability Statement for Secure Health Transport v1.1 and (if implementing) the XDR and XDM for Direct Messaging specifications.

• Minimize data collection, use, retention and disclosure to that minimally required to meet the level of service required of the HISP. To the extent that HISPs support multiple functions with different requirements for data use, they must separate those functions such that more extensive data use or disclosure is not required for more basic (Direct) exchange models.

• Determine whether they are business associates (BAs) and hold themselves to the provisions of the HIPAA Security Rule, as amended by the HITECH Act, that are applicable to BAs.

- 67 -

Areas of General Consensus w/ State HIE Program Recommendations

• Encrypt all edge protocol communications that enable ‘last mile’ exchange between end-users’ systems and an STA/HISP’s Direct infrastructure by using SSL/TLS or similar industry standard.

• For HISPs that manage private keys -- perform specific risk assessment and risk mitigation to ensure that the private keys have the strongest protection from unauthorized use.

• For HISPs that manage trust anchors on behalf of their customers -- have well defined, publicly available policies that permit customers and other parties to evaluate the HISP’s certificate issuance (and trust management) policies.

• Only facilitate Direct messages that utilize digital certificates which conform to related RA/CA certificate guidance (Note: details of the RA/CA requirements will be handled later).

- 68 -

Areas of General Consensus w/ State HIE Program Recommendationswith Significant Extensions by Trust Communities

• Have contractually binding legal agreements with their clients (who send and receive Individually Identifiable Health Information [IIHI] using Direct), including all terms and conditions required in a Business Associate Agreement (BAA).

• In particular, efforts have focused on the definition of specific obligations for data senders and recipients, especially what data recipients may or may not do with the data they receive. However, these issues are generally covered by existing national and state laws and regulations.

• Demonstrate (through either availability of a written security audit report or formal accreditation provided by an established, independent third-party entity) conformance with industry standard practices related to meeting privacy and security regulations in terms of both technical performance and business processes.

• In particular, efforts have focused on the definition of either acceptable existing security audits and/or specification of requirements for new accreditation programs.

- 69 -

Suggested Enhancements to Existing State HIE Program Recommendations

- 70 -

• In addition to encryption (which is already specified), authenticate all edge protocol communications that enable ‘last mile’ exchange between end-users’ systems and an STA/HISP’s Direct infrastructure.

Lunch

We’ll resume the meeting at 1:30 PM.

Identity Validation and Certificate Issuance

John HallDebbie Bucci

State HIE Program Recommendations for RAs/CAs (Identity Validation)

• For identity validation of non-patient entities:

• RAs, CAs and any other entities performing RA functions should ensure that individuals and organizations are identity proofed at the medium assurance level (as specified in FBCA X.509 Certificate Policy for the Federal Bridge Certification Authority Dec. 9, 2011). The identity of the applicant must be established no earlier than 30 days prior to the initial certificate issuance.

- 73 -


• Detailed requirements for non-patient entities:

• For individual end-users – identity is established by in-person proofing before the Registration Authority, Trusted Agent or an entity certified by a State or Federal Entity as being authorized to confirm identities (such as a notary public) using federal government-issued photo ID, a REAL ID Act compliant photo ID or two non-federal IDs, one of which is a photo ID (e.g., Non-REAL ID Act compliant Drivers License). All credentials must be unexpired. A trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent, may suffice as meeting the in-person identity proofing requirement.

• For organizations – is set out in the FBCA Certificate Policy, identity is established

by a representative of the organization (from the Information Systems Security Office or equivalent) providing the organization name, address, and documentation of the existence of the organization. In addition to verifying this information, the RA must verify the authenticity of the requesting representative (at the medium level of assurance) and the representative’s authorization to act in the name of the organization to control of the organization’s group certificate private key.

- 74 -


• Additional requirement:

• An organization participating in a HISP must be a HIPAA covered entity, a business associate of a HIPAA covered entity, or be a person or organization who is involved in health care related activities and who agrees to hold themselves to the same security requirements as provided in the HIPAA Security Rule.

- 75 -

Areas of General Consensus w/ State HIE Program Recommendationsfor Identity Validation

• The Direct community is generally supportive of the need for robust identity validation of both individuals and organizations and existing practice by HISPs/HIEs at least attempts to generally align with these methods

• The Direct community supports the additional requirement of ‘healthcare affiliated’ entities (i.e., not just providers/patients) engaging in directed exchanges

However…

• The Direct community has expressed concerns about differences between FBCA and NIST levels of assurance (see reference slides)

• The Direct community has also expressed a desire to engage in remote identity validation of end-users

- 76 -

State HIE Program Recommendations for RAs/CAs (Certificate Issuance)

• CAs should be cross-certified to the Federal Bridge Certification Authority (FBCA) and issue/utilize a certificate policy (CP) and certificate practice statement (CPS) that conforms to FBCA cross-certified requirements. In particular, the CA should issue certificates that:

• Are cross certified to the Federal Bridge Certification Authority (FBCA)• Are issued to a health care related organization or more granular

component of an organization (e.g., department, individual). One certificate issued to a HISP to use on behalf of all participants in the HISP does not meet this criterion.

• Conform to required assurance criteria• Do not have non-repudiation flag set • Conform to other requirements set forth in Applicability Statement for

Secure Health Transport

- 77 -

Gaps in Consensus with State HIE Program Recommendations for RAs/CAs (Certificate Issuance)

• While many entities have policies which “align with” (or are claimed to do so) with the Federal Bridge Certification Authority (FBCA), many community members have expressed reservations about actually issuing FBCA cross-certified certificates

• Let’s talk about why FBCA was included in the State HIE Program guidelines• Let’s explore possible alternatives to FBCA• Let’s consider potential paths forward

• Some individual HISPs / HIEs have expressed a desire to employ a single HISP-wide certificate to use on behalf of all participants in the HISP

• Let’s talk about why this requirement was included in the State HIE Program guidelines

• Let’s discuss why trust communities also don’t support a single, HISP-wide certificate in their participation requirements

• Let’s consider how we can/should make this requirement less ambiguous

- 78 -

Gaps in Consensus with State HIE Program Recommendations for RAs/CAs (Identity Validation)

• The decision about whether or not to use FBCA Certificates has implications for identity proofing requirements for individual end-users

• If stick with FBCA, keep Medium requirements?

• If pick alternative to FBCA, use LOA3 requirements to align with proposed MUS3?

• Either way, allow for remote identity proofing? (which is acceptable for both Medium and LOA3)

- 79 -

Break

Please meet back in Potomac D&E in 15 minutes!

Trust Anchor Distribution Mechanisms

John HallPaul Tuten

Direct and Trust Anchors

• Within Direct, messages are transported only between trusted parties.

• The technical expression of a trust relationship is through the mutual exchange of trusted anchor certificates, or trust anchors.

• The Applicability Statement does not define mechanisms through which trust anchors are exchanged or maintained.

- 82 -

Manual Exchange of Trust Anchors

• In the absence of defined mechanisms for trust anchor exchange and maintenance, parties forming trust relationships are using one-off manual operations.

• However, manual exchange and maintenance of trust anchors doesn’t scale beyond the smallest of numbers – N-squared problem.

- 83 -

Trust Anchor Distribution

• There’s broad recognition that one-off manual exchange of trust anchors doesn’t scale.

• Trust anchor distribution is often discussed within the ecosystem and is a common component of trust communities.

• As members join a trust community, the community aggregates their associated trust anchors.

• This aggregation of anchors, sometimes referred to as a “bundle”, is made available to the entire community.

• Members of the trust community configure their STAs to trust the anchors in the bundle.

- 84 -

Examples of Trust Anchor Distribution Mechanisms

Numerous potential mechanisms to distribute trust anchors have been raised in the past, including:

• Package Download

• Command Channel

• Web Service

(These are simply examples illustrating possibilities. We will not be going into plusses/minuses of each since we’re not trying to build consensus today around a specific approach.)

- 85 -

Trust Anchor Distribution Option: Package Download

• Trust community aggregates its trust anchor bundle into a structured package (e.g., TAR, ZIP) and makes it available for download at a standard location using a standard protocol (e.g., HTTP, FTP).

• Upon joining the trust community, members download the trust anchor bundle package and configure their STAs to trust the anchors within the bundle.

• Trust community re-publishes its trust anchor bundle package as the bundle changes. Members periodically and regularly re-download the package and refresh the configuration of their STAs. This could be automated or have manual components.

• Members might have the option of downloading and dealing with smaller “delta” packages that only contain new or updated anchors as well as data detailing trust anchors that should be deleted. Depending on how current a member’s local version of the trust bundle is, multiple “deltas” may need to be downloaded and applied.

- 86 -

Trust Anchor Distribution Option: Command Channel

• Starts similarly to Package Download Option – trust community makes available to members its trust anchor bundle at a standard location via a standard protocol, and new members download the trust anchor bundle and configure their STAs to trust the anchors within the bundle.

• Trust community subsequently communicates changes to the bundle as they occur using Direct messages.

• Messages are from a Direct address dedicated by standard.• Contain a command or set of commands – Add, Update, Delete• Contain appropriate information to act on commands, e.g., anchor to add.• Structured to be computable for automated processing.

• Member STAs receive these “command” messages at dedicated addresses, process them, and act on them accordingly, thereby keeping their trust bundle configurations synchronized.

- 87 -

Trust Anchor Distribution Option: Web Service

• Trust community offers a web service that enables members to access its trust anchor bundle.

• Using the web service, members can:• Populate the configuration of their STAs with the trust anchors in the current

bundle• Query for changes to the bundle and synchronize their STAs accordingly

• Members use the web service to initialize the trust bundle configuration of their STAs upon joining the trust community and regularly query the service to keep their STAs synchronized.

• Web service could be:• RESTful, building upon standards such as ATOM/RSS• SOAP-based

- 88 -

Trust Anchor Distribution (Redux)

It’s great that there are options for trust anchor distribution, but multiple approaches taken within the ecosystem will create problems for solution providers, hinder interoperability between trust communities, and present serious challenges to scaling trust.

- 89 -

Trust Organization A

HISP BHISP A


Trust Organization B

HISP DHISP C


X X

X X

Working Together on a Common Approach to Trust Anchor Distribution

• Subgroup of Direct Project’s Implementation Geographies Workgroup• Determine common technical approach to trust anchor distribution• Develop implementation guide• Pilot implementation guide• Refine implementation guide as needed based on pilots

• Potential timeline• Determine technical approach – by mid Jan 2012• Develop implementation guide – by mid Feb 2013• Pilot implementation guide – through mid Apr 2013• Refine implementation guide – by end Apr 2013

• Who’d like to participate? • We’ve got a sign-up sheet• We’ll hold an “Open Space” session tomorrow to kick-off this effort

- 90 -

Closing Remarks

Paul Tuten

Reminders

• We start tomorrow at 8 am. Please remember to bring back your consensus cards

• We’ll end tomorrow at 1 pm, but we encourage you to continue discussions after the meeting in the hotel lobby or at restaurants in the area

• We’ve made arrangements for an optional social event tonight @ 6:30:

• BELL20 Restaurant in the lobby of Crystal City Marriot

- 92 -

Direct Scalable Trust Forum – Day 2

November 30, 2012

Agenda – Day 2

- 94 -

Day 2 – 11/30 8:00 – 1:00 PM ET

8:00 = 8:30 AM Day #1 Meeting Recap Paul Tuten, ONC ContractorClaudia Williams, State HIE Program Director

8:30 – 9:30 Business Practices/Requirements That Could Reduce the Need for, or Simplify, HISP to HISP Agreements

Erica Galvez, State HIE Community of Practice Director

9:30 – 9:45 AM BREAK

9:45 – 10:00 AM “Open Space” Meeting Set up and Ground Rules Discussion

Erica Galvez, State HIE Community of Practice Director

10:00 – 11:00 AM Breakout Session 1

11:00 – 12:00 PM Breakout Session 2

12:00 – 1:00 PM Next Steps, and Concluding Remarks Paul Tuten, ONC ContractorClaudia Williams, State HIE Program Director

Business Practices/Requirements That Could Reduce the Need for HISP to HISP Agreements

Erica Galvez

Business Practices/Requirements That Could Reduce the Need for HISP to HISP Agreements

- 96 -

• Needing peer to peer agreements between all HISPs is not a scalable approach to support ubiquitous directed exchange

• What other business practices, requirements or policies must be addressed to obviate the need for one-off HISP-to-HISP agreements for Direct message exchange?

• Some examples to consider:

• Should trust communities also require common operational characteristics for participating HISPs (e.g., service availability?)

• Should participation within a trust community imply unfettered Direct message exchange between all members of the community (i.e., a form of “network neutrality”)?

• Should HISPs participating in trust communities agree not to charge fees for basic send and receive functions from other HISPs?

“Open Space” Meeting Setup and Ground Rules Discussion

Erica Galvez

Henri Lipmanowicz & Keith McCandless

Open SpaceTechnology

Liberating Inherent Creativity & Leadership In Large Groups with an Action-Orientation

Open SpaceTechnology

Liberating Inherent Creativity & Leadership In Large Groups with an Action-Orientation


Freedom

Responsibility

Open Space Boosts Freedom AND Responsibility

Open Space PurposeOpen Space PurposeTo facilitate discussions and collaboration between Direct

implementers that:

(1) Address important issues we were unable to cover in the previous sessions

(2) Further the goal of enabling providers to seamlessly exchange patient information with each other using Direct across vendor and provider boundaries as the field moves into stage 2 of meaningful use.

(3) Unleash creative thinking, and build partnerships that leverage existing investments in Direct

To facilitate discussions and collaboration between Direct implementers that:

(1) Address important issues we were unable to cover in the

previous sessions(2) Further the goal of enabling providers to seamlessly

exchange patient information with each other using Direct across vendor and provider boundaries as the field moves into stage 2 of meaningful use.

(3) Unleash creative thinking, and build partnerships that leverage existing investments in Direct

Open Space Minimum Specifications

Open Space Minimum Specifications

Discussions and collaborations should:• Support ubiquitous directed exchange

• Focus on issues and solutions that can reach widespread implementation in 6-12 months

• Work toward minimum necessary, and nothing less Don’t let the perfect be the enemy of the good enough Go for 80 percent everyone can agree on

• Be feasible with (roughly) current resources

Motivation, knowledge and funding

Discussions and collaborations should:• Support ubiquitous directed exchange

• Focus on issues and solutions that can reach widespread implementation in 6-12 months

• Work toward minimum necessary, and nothing less Don’t let the perfect be the enemy of the good enough Go for 80 percent everyone can agree on

• Be feasible with (roughly) current resources

Motivation, knowledge and funding


Four Principles and One Law Be prepared to be surprised; and,

let your passion guide you

Law of Two Feet• go to where you are learning or contributing

Principles of Open Space• Whoever comes is the right people• Whatever happens is the only thing that could have• Whenever it starts is the right time• When it is over it is over

Law of Two Feet• go to where you are learning or contributing

Principles of Open Space• Whoever comes is the right people• Whatever happens is the only thing that could have• Whenever it starts is the right time• When it is over it is over

Open Space Breakout Session Guide

103

Session A B C

1

10:00-11:00 AM

What do we do in the meantime?

Convener: Lee Jones

Overview of DirectTrust.org

Convener: David Kibbe

Provider directory and 360X piloting

Convener: Peter Bachman

2

11:00-12:00 PM

Mechanisms for distributing trust bundles

Convener: Rim Cothren

EHR-HISP bundling for MU2

Convener: Gary Christensen

Identity & agency are NOT health care specific, attributes & directories ARE health care specific

Convener: Adrian Gropper

Open Space Meeting Agenda

Next Steps and Concluding Remarks

Claudia Williams Paul Tuten

Discussion

• What key insights / learning / discussions occurred in the open space sessions?

• Are there additional high priority actions that are needed?

• How do we move forward from this meeting? What are the important next steps?

- 105 -

Reminders

• Don’t forget to…

• Sign-up for Trust Anchor Bundle Distribution Workgroup

• Download presentation slides from Direct Project wiki

• Complete evaluation forms

- 106 -

Thanks!.

- 107 -

Summary Slides

Organization Distribution*

- 109 -

Health In-formation Service Provider

(HISP)

Certifi-cate Au-thority

Federal Agency

Registra-tion Au-thority

EHR Vendor

State HIE Grantee

Contrac-tor

Trust Frame-work

Provider

Other

108

25

12

7

5

2

7

7

Other Includes:

• Patient Privacy Rights• Provider• Accreditation • Professional Society• Software Company• Consumer Advocate• Standards Based

Community

Total number of forum participants: 69

*Some participants represented more than one organization at the forum

Key Takeaways – Day 1

• HISP-to-HISP interoperability is vital, yet remains a challenge.

• Trust umbrella organizations (i.e., trust communities) represent one viable and valuable path toward achieving ‘scalable trust’.

• LOA3 Identity Verification / FBCA Basic (or equivalent) processes are an appropriate/acceptable baseline for certificate issuance / management.

• Implementations based on a single, HISP-wide certificate are not acceptable.

• There is general consensus around the State HIE Program’s HISP operating guidelines. Additional detail/specification is needed in a few areas (e.g., issue of use/re-use of data by HISPs/HIEs).

• Group should work together to conduct pilots to establish a common mechanism for trust anchor bundle exchange.

• Defining a ‘glide path’ (interim steps) and education are important next steps.

- 110 -

Key Takeaways – Day 2

• The risk management and legal community must be educated in order to establish any form of accreditation.

• It’s not just the wires that need agreements, it’s the disclosers that need them as well.

• A common “package” of elements to avoid HISP-to-HISP agreements may include:

• BAA HISP Provider• Dispute resolution among HISPs• Explicit transparent accreditation • Clarification on breach/safe harbor• Auditing/enforcement by accrediting body• Federated trust agreement

• Group needs to manage expectations during this process; especially, acknowledge that everyone will not agree to participate right away.

- 111 -

Key Takeaways – Breakout Sessions

- 112 -

• A1 – “What do we do in the meantime?” – Lee Joneso The group decided to endorse three points:

1. We agree with the need to address trust issue with a scalable solution.

2. We do not support HISP to HISP agreements.3. We understand that we have to be transparent, so we will publish our

list of attributes that explain our current state of practice and policies, i.e., a registry of all HISPs that abide by community’s guidance.

o Action Item: Draft language/guidance on how to describe this initial step towards interoperability.

• B1 – “Overview of DirectTrust.org” – David Kibbeo Elements of accreditation will be published by the end of December, and

will be taking applications on February 1st. o We will have 6-8 accredited entities by March. o Rhode Island is going to adopt this accreditation to replace their existing

one.o Action Item: Publish the outcomes of this forum and develop education to

providers, legal communities, and EHR vendors about accreditation process.


- 113 -

• C1 – “Provider Directories and 360X Piloting” – Peter Bachmano The trust bar for the developed methodology around referrals and

provider directories has been set too high; we would like to lower the trust bar.

o Identity is imperative to know who you’re dealing with and a national framework to structure should be pursued, i.e., HISP or owner of the provider directory should have the authority to verify certificates.

o Next step: Find pilot participants for the 360X Project that is supported by ONC.

• A2 – “Mechanisms for distributing trust bundles” – Rim Cothreno There are two organizations working through this problem; the group

identified overlapping issues and reaffirmed that we’re talking about a collection of trust anchors.

o Next step: Must have HISP representation in the Implementation Geographies sub-workgroup.


- 114 -

• B2 – “EHR-HISP bundling for MU2” – Gary Christensen o A good number of the rooms’ leaders had not processed the implications

of MU2 on certification participants. o There were two items passed forward for people to think about in terms of

how this relates to a business model:1. Encourage the EHR marketplace to adopt the XDR piece2. There may be creative thinking that will fit within constraints, so we

encourage the group and ONC to do this thinking. o Action Item: Repeat webinar that was presented to HIEs for NEHIC.

• C2 – “Identity and Agency are NOT healthcare specific” – Adrian Groppero The group put together a two part consensus statement to be used as a

test in this process:1. If identity or IDP is not applicable across industries, it is the wrong

solution.2. HISPs must be substitutable agents of the licensed providers or data

holders. o Action Item: Group asked ONC to seek clarity moving forward with

respect to these two questions.

Milestones and Dates

- 115 -

• February 2013: Complete a set of “Ready to Go” policies, guidance, pilots, and education for vendors/providers.

• April 2013: Accreditation bodies to be formed, operating, and ready for business.

• September 2013: >50% of HISPs/CAs serving providers for MU2 are participating in accreditation.

Action Items for the Community

- 116 -

Item Proposed Due Date

Form and participate in workgroup to automate trust bundle distribution

December 2012

Form and participate in workgroup on refining “package” of requirements to avoid/limit need for HISP to HISP agreements

December 2012

Form and participate in workgroup on “what to do in the meantime”

December 2012

Find pilot participants for the 360X Project that is supported by ONC Ongoing

Reference

Policy Disconnects

• FPKI FBCA policies work predates the SP 800-63 specification, thus the security requirements are not always strictly aligned.

• SP 800 63 1acknowledges the gaps; currently has delegated FBCA primary guidance at LOA3/LOA4 for certificate use

• Certificate use will depend on individual implementations• Both FBCA and SP 800-63-1 are official guidance for Federal partners

supporting Direct• HIPPA guidance very general leaving much open to interpretation. No actual

references to identity proofing requirements.

- 118 -

• DEA e-prescribe• Two-factor authentication equivalent of signing method. SP-800-63-1

primary guidance.• DEA license must be associated with credential – can indirectly map to

previous in-person identity proofing• Rule recognizes and approves use of existing provider practices to serve

as trusted agents• Both in-person and remote identity proofing allowed. Extended to

support rural providers• Non-repudiation required• Interim rule – updates in technology may change requirements

• Example – State of VA allows teleconferencing techniques for in-person verification

• esMD• PKI certificate for signing in near term – FBCA primary guidance• Medium certificate - specifically for monetary fraud risks that may occur

in payee environment• Considering use of Direct for commercial payers• Identity proofing requirements align with NIST 800 63 -1• Non-repudiation required

- 119 -

Requirement vary across initiatives

04/11/2023

FPKI LOA Assurance description

CRL/RevocationRe-Key

800-63-1 Token and LOA

800-63-1ID Proofing

Basic Basic level of risk and compromise. Likelihood of malicious access not high

24 hrs./24 hrs.15 yrs.

LOA3 LOA3

Medium Moderate risk and compromise – includes monetary value or risk of fraud

24 hrs./18hrs.9 yrs.

LOA3 LOA4

Medium Hardware

High risk 24 hrs./18 hrs.9 yrs.

LOA4 LOA4

High Reserved for cross-certification with government entities. High Risk

24 hrs./6 hrs.3 yrs.

LOA4 LOA4

FBCA Certificate Types

- 120 -

FBCA Information required

04/11/2023

Basic Medium High

In person

ID number or account that could be used to confirm name, DoB, address and other personal information

One Federal Government-issued Picture I.D. or Real Act ID, or two Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Drivers License)

Same as Medium

Remote ID number or account that could be used to confirm name, DoB, address and other personal information

One Federal Government-issued Picture I.D. or Real Act ID, or two Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Drivers License) andAntecedent shared attributes or secrets from previous in-person event

Not applicable for HIGH

- 121 -

800-63-1 Required Information

04/11/2023

Level 2 Level 3 Level 4

In person

Possession of valid current primary Government Picture ID• applicant’s picture, and • either address of record or nationality of record(e.g. driver’s license or passport)

Level 2 plus •ID must be verified

Level 3 plus validated second government ID or a validated financial account number. Note: utility account information not acceptable for LOA4

Remote • Possession of a valid Government ID (e.g. a driver’s license or passport) number and • Financial account number (e.g., checking account, savings account, loan or credit card) or utility account number with confirmation via records of either number.

Same as Level 2 but confirmation via records of both numbers.

Not applicable for LOA4

- 122 -

direct scalable trust forum

Health & Medicine