Direct Scalable Trust Forum


Published on

Published in: Health & Medicine
1 Comment
  • Awesome post,nice content.I had bookmarked your post.Reading your blog continuously.

    Thanks for the great article.There are many things I have flat know from your posts.Thank you very much..

    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Trust Organization – take out umbrella? Be consistent.
  • Pull elements out of the application into the cloud Shifts enforcement of security, privacy and rights management policies off of individual applications and on to a shared neutral network example of access control. Identity – users can be identified through a federated network of identity servicesAccording to John Mattison, Kaiser Chief Medical information officer, 18-20 pages of single space list of people named Maria Gonzales in the Kaiser system, in SOUTHERN CALIFORNIA alone. Single business issue in health information exchange. *****************************************************Security model allows for granular control of resources after they are sharedUnlocks formerly un-sharable and un-monetizable resources Enables convenient ad hoc sharing of sensitive information between organizations without consensus on policies, and without requiring legal data sharing agreementsControl – owner maintains end to end control of their dataSecurity – level of security can be different for different levels of data – health insurance information vs HIV statusPolicies – defined by the data owner and enforced by the networkPrivacy – users don’t know who they are exchanging data with and don'
  • Trust Services (third parties) Verify identities and relationships Enforce security, privacy and payment policiesWhy is this a better approach to traditional information exchange? -- eliminates need for point to point integration -- no DURSA -- data is combined in real time when you need it
  • Trust Services (third parties) Verify identities and relationships Enforce security, privacy and payment policiesWhy is this a better approach to traditional information exchange? -- eliminates need for point to point integration -- no DURSA -- data is combined in real time when you need it
  • Trust Services (third parties) Verify identities and relationships Enforce security, privacy and payment policiesWhy is this a better approach to traditional information exchange? -- eliminates need for point to point integration -- no DURSA -- data is combined in real time when you need it
  • Direct Scalable Trust Forum

    1. 1. Direct Scalable Trust ForumNovember 29 – November 30, 2012
    2. 2. WelcomeFarzad Mostashari
    3. 3. Putting “Scalable Trust withoutGovernance” in ContextClaudia Williams
    4. 4. 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-
    5. 5. 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-
    6. 6. 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-
    7. 7. Agenda, Ground Rules, and “What WeMean by Scalable Trust?”Paul Tuten
    8. 8. Agenda – Day 1Day 1 – 10/31 9:00 – 5:30 PM ET9 – 9:15 AM Welcome Farzad Mostashari, National Coordinator9:15 – 9:30 AM ―Scalable Trust‖ In Context Claudia Williams, State HIE Program Director Agenda and ―What Do We Mean By Scalable Trust?‖ Paul Tuten, ONC Contractor9: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 BREAK10:45 – 12:15 PM HISP Privacy & Security Safeguards / Operating Policies John Feikema, S&I Framework Coordinator Paul Tuten, ONC Contractor12:15 – 1:30 PM BREAK FOR LUNCH1:30 – 3:30 PM Identity Verification and Certificate Issuance John Hall, Direct Project Coordinator Debbie Bucci, Security Advisor3:30 – 3:45 PM BREAK3:45 – 5:15 PM Trust Anchor Distribution Mechanisms John Hall, Direct Project Coordinator Paul Tuten, ONC Contractor5:15 – 5:30 PM Closing Remarks Paul Tuten, ONC Contractor -8-
    9. 9. 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-
    10. 10. 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 -
    11. 11. 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 -
    12. 12. 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 -
    13. 13. 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 -
    14. 14. What is Scalable Trust?An efficient means of enabling Direct exchange between participants on disparateHISPs. Fundamentally, it is predicated on two things: • Common trust frameworks / policies • Technical mechanisms to automate trust between framework participants - 14 -
    15. 15. Scalable Trust in “Three Easy Steps”1. Trust Umbrella Organization defines requirements for participation2. Trust Umbrella Organization enrolls/accredits/certifies entities to be included in an Trust Anchor Bundle3. Trust Umbrella Organization enables mechanism for electronic distribution of Trust Anchor Bundle to all members - 15 -
    16. 16. Example of Scalable Trust Model Trust Organization Centralized Trust Anchor Bundle Store Provider B HISP A HISP B Provider A - 16 -
    17. 17. Example of Scalable Trust Model: New HISP Joins Trust Organization Trust Organization Centralized Trust Anchor Bundle Store Provider B HISP A HISP B Provider A Provider C HISP C - 17 -
    18. 18. Example of Scalable Trust Model: Peer-to-Peer Reciprocity Trust Organization A Trust Organization B Centralized Trust Anchor Bundle Store Centralized Trust Anchor Bundle Store HISP A HISP B HISP C HISP D This is the aim of this meeting: working toward sufficient alignment—while allowing for differences—to enable widespread interoperability - 18 -
    19. 19. Overview of Direct-focused TrustFrameworks / EffortsDavid Kibbe – DirectTrustAaron Seib – Western States ConsortiumBrian Ahier – NSTIC Pilot
    20. 20. DirectTrust Direct Scalable Trust Forum November 29, 2012 David C. Kibbe, MD MBA President and CEO12/9/2012 20
    21. 21. 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.12/9/2012 21
    22. 22. Current Members*• American Academy of Family • McKesson Corporation Physicians • MedAllies• Cerner Corporation • Medicity• DigiCert • Morrell Taggard, Inc.• EHNAC • Ohio Health Info Partnership• Gemalto • Nitor Group• Gorge Health Connect • Redwood Mednet• HealthcareXchange • Rhode Island Quality Institute• HealthShare Montana • SAFE Bio Pharma Assoc.• Healthwise • State of Tennessee• Informatics Corp of America • Surescripts• Lexis Nexis • Techsant Technologies• MaxMD • Walgreens * had over 200 members of its wiki when the transition to a Membership model of organization began in October, 2012.12/9/2012 22
    23. 23. 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.12/9/2012 23
    24. 24. DirectTrust Direct Project Rules wiki of the Road established incorporated workgroup formed December 2012 April 2012 April 2011 "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."12/9/2012 24
    25. 25. DirectTrust X.509 Testing and Trusted Anchor Certificate Accreditation Bundle Recognition Policy Program Program Distribution Established Service Sept. 2012 Feb. 2013 Dec. 2011 March 2013 ”Within the context of Directed exchange, Trust Agents include Health Information Service Providers, HISPs, Certificate Authorities, CAs, and Registration Authorities, RA s”12/9/2012 25
    26. 26. 12/9/2012 26
    27. 27. Direct Trusted Agent Accreditation Program, DTAAP12/9/2012 27
    28. 28. Direct Trusted Agent Accreditation Program, DTAAP Example Criteria from Section II12/9/2012 28
    29. 29. Strategic Context The Direct Project. Blue Button Initiative. EPCS. NSTIC. Stage 2 Meaningful Use objectives for Care Coordination and Patient Engagement. ACOs. RHEx.• 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. 12/9/2012 29
    30. 30. Workgroups Security and Trust Compliance Certificate Citizen and Policy and Patient Practices Participation12/9/2012 30
    31. 31. Security and Trust Compliance WorkgroupChair Andy Heeren, Cerner CorporationPurpose 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 DiscussionsUpcoming • Accreditation Program Development12/9/2012 31
    32. 32. Certificate Practices and Policy WorkgroupChair Don Jorgenson, Inpriva Scott Rea, DigiCertPurpose 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 • Ecosystem Community X.509 Certificate Policy - Draft for Trial Use completeActive • 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 Questions12/9/2012 32
    33. 33. Citizen and Patient Participation WorkgroupChair Leslie Kelly-Hall, HealthWisePurpose 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.CompletedActive • 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 StatementUpcoming • So You Want to be a HISP? • Guidance via Frequently Asked Questions12/9/2012 33
    34. 34. 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 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)12/9/2012 34
    35. 35. Western States ConsortiumNovember 29, 2012Scaling Trust Briefing
    36. 36. 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
    37. 37. 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.
    38. 38. 38
    39. 39. 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.
    40. 40. 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.
    41. 41. 41Work 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
    42. 42. 42 Executing WSC – Pilot Scenarios• Formation of a Multi-state Governance Body • Pilot Scenario‟s 1 & 2 and beyond
    43. 43. 43Pilot Landscape
    44. 44. 44WSC-MOU; Relationships; Policies and Procedures
    45. 45. 45Key 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
    46. 46. 46Test Message sent November 1, 2012
    47. 47. Western States Consortium Pilot ScenariosUse 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.
    48. 48. 48Scenario 1 and Scenario 2.a & 2.bWithin the Trust Community of the WSC-Pilot:Scenario 1:Executed the independent evaluation of each state‟s respective Pilot-HISP forcompliance with common Eligibility Criteria as defined by the Governance Body.Employed shared trust bundle methodology to make Qualified HISPs discoverableto one another. (Live November 1)Scenario 2.a:Implementing address discovery using open-standards based query of HISP‟sdirectories across state lines. The query standard we are currently working with isbased 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 manyHISPs in CA. California will be the first to implement these methods of federationusing statewide orchestration services in pilot mode among HIOs in CA.(Assuming go-decision based on experience of running 2.a ~ Release 1.0 of theCalifornia is expected to launch mid-January)
    49. 49. 49Governance of Trust Communities, Accreditation and Innovation
    50. 50. 50Where does Accreditation andGovernance 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.
    51. 51. 51From State HIE Direct CoP meeting November 19, 2012 – John Hall Presentation
    52. 52. 52Terms 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
    53. 53. 53Technical Certification and Accreditationcontribute 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.
    54. 54. 54What is important about a model like theWSC 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.
    55. 55. 55Governance and Accreditation – complimentarycomponents for scaling trust & innovationGovernance includes management and enforcement to rules, amongother functions, some of which might be covered within anAccreditation Program, but not all.A few explicit governance roles and issues that may be addressed by aGovernance entity such as the WSC but not necessarily by anaccreditation 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.
    56. 56. NSTIC Pilot Project Scalable TrustInvestor Presentation Q2 2012 November 29, 2012
    57. 57. & National Strategy for Trusted Identities in Cyberspace• Signed by the President in 2011 • Resilient awarded 12 month, $2M• Create new Identity Ecosystems grant to pilot innovative solutions for to assure security and privacy both healthcare and education• Pilot grants and an adoption requirement for .Gov websites • 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”
    58. 58. Goals of the NSTIC PilotHealthcare: 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
    59. 59. Healthcare: Patient-Centered Coordination of CarePilot Sites & HIE Software: Highlights of Pilot • Populations of seasonal agricultural workers from SD work and received care in Oregon too • Identity matching and policy enforcement enables coordinationDecision Support Partners: • Enable NwHIN Direct messaging across HIE platforms and state lines • Novel, cloud-based decision support available to doctors in both states • On-demand, privacy-preservingIdentity & Attribute Providers: authentication and authorization • Commercialized identity matching, secure messaging & cloud-based decision support can scale rapidlyAdvisors on Governance / Protocols / Policy: Principal Investigator Dr. David Hartzband, D.Sc. Chief Technology Officer Resilient Network Systems
    60. 60. The TrustTrust NetworkResilient NetworkAn “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
    61. 61. Coordination of Care eReferral Messaging input Clinical input • “Closes the Loop” Decision • Handles Identities Support “In the Network” Primary Care & Cardiologist Powered by: for use of portals Physician results results and web services • Resolves policies within and across: • Organizations • Tech platforms • State lines • Interoperable Transfer of Care Messaging
    62. 62. Identity Syndication Verified Identity 1. “I am Dr. John Smith” Dr. Smith 2. “I am a Cardiologist” Enabled for Use user Identity Syndicate Aggregates and organizes 2nd Claim Confirmed 1st Claim Confirmed Identity Broker identity attributes Correlates, verifies (inputs from ID Broker) and and authenticates calculates Levels of identities of users Certainty and records. Identity Syndicate InconclusiveIdentity Providers Maybe Maybe- Commercial ID Yes Yes YesProviders- Professional HIE / LexisNexi NaviNet AMAassociations- Other applications, HISP s directories and services
    63. 63. Trust Enables : Authorized Relationships Notification of information requiring authorizationPhysician Staff Staff PhysicianOffice 1 Office 2 Establishes Trust Graphs byDr. Smith enforcing the policies that Dr. Brown Dr. Smith’s Office form these relationships Dr. Brown’s Office Authorized Authorized Relationships Relationships Patient Patient Trust Encrypted exchange Trust Graph 1 can now occur Graph 2
    64. 64. Expansion and Connections to Other InitiativesDIRECT 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 NSTICCollaborative and Cloud-based Healthcare Apps/Services Aetna Strategic Services • ActiveHealth CareEngine™ • Medicity HIE, and iNEXX Platform
    65. 65. BreakPlease meet back in Potomac D&E in 15 minutes!
    66. 66. HISP Privacy & Security Safeguards /Operating PoliciesJohn FeikemaPaul Tuten
    67. 67. 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 -
    68. 68. 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 -
    69. 69. 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 -
    70. 70. Suggested Enhancements to Existing State HIE Program Recommendations • 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. - 70 -
    71. 71. LunchWe’ll resume the meeting at 1:30 PM.
    72. 72. Identity Validation and Certificate IssuanceJohn HallDebbie Bucci
    73. 73. 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 -
    74. 74. State HIE Program Recommendations for RAs/CAs (Identity Validation) • 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 -
    75. 75. State HIE Program Recommendations for RAs/CAs (Identity Validation) • 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 -
    76. 76. 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 -
    77. 77. 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 -
    78. 78. 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 -
    79. 79. 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 -
    80. 80. BreakPlease meet back in Potomac D&E in 15 minutes!
    81. 81. Trust Anchor Distribution MechanismsJohn HallPaul Tuten
    82. 82. 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 -
    83. 83. 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 -
    84. 84. 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 -
    85. 85. 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 -
    86. 86. 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 -
    87. 87. 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 -
    88. 88. 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 -
    89. 89. 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. Trust Organization A Trust Organization B Centralized Trust Anchor Bundle Store Centralized Trust Anchor Bundle Store X X X X HISP A HISP B HISP C HISP D - 89 -
    90. 90. 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 -
    91. 91. Closing RemarksPaul Tuten
    92. 92. 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 -
    93. 93. Direct Scalable Trust Forum – Day 2November 30, 2012
    94. 94. Agenda – Day 2Day 2 – 11/30 8:00 – 1:00 PM ET8:00 = 8:30 AM Day #1 Meeting Recap Paul Tuten, ONC Contractor Claudia Williams, State HIE Program Director8:30 – 9:30 Business Practices/Requirements That Could Reduce the Erica Galvez, State HIE Community of Need for, or Simplify, HISP to HISP Agreements Practice Director9:30 – 9:45 AM BREAK9:45 – 10:00 AM ―Open Space‖ Meeting Set up and Ground Rules Erica Galvez, State HIE Community of Discussion Practice Director10:00 – 11:00 AM Breakout Session 111:00 – 12:00 PM Breakout Session 212:00 – 1:00 PM Next Steps, and Concluding Remarks Paul Tuten, ONC Contractor Claudia Williams, State HIE Program Director - 94 -
    95. 95. Business Practices/Requirements ThatCould Reduce the Need for HISP to HISPAgreementsErica Galvez
    96. 96. Business Practices/Requirements That Could Reduce the Need for HISP toHISP Agreements • 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? - 96 -
    97. 97. “Open Space” Meeting Setup and GroundRules DiscussionErica Galvez
    98. 98. Open Space TechnologyLiberating Inherent Creativity & Leadership Henri Lipmanowicz & Keith McCandlessIn Large Groups with an Action-Orientation
    99. 99. Open Space Boosts Freedom AND Responsibility Freedom Responsibility Henri Lipmanowicz & Keith McCandless
    100. 100. Open Space Purpose 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
    101. 101. Open Space Minimum SpecificationsDiscussions 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
    102. 102. Four Principles and One Law Be prepared to be surprised; and, let your passion guide youLaw of Two Feet• go to where you are learning or contributingPrinciples 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 Henri Lipmanowicz & Keith McCandless
    103. 103. Open Space Meeting Agenda Open Space Breakout SessionSession A Guide B C 1 What do we do in the Overview of Provider directory meantime? and 360X piloting10:00-11:00 AM Convener: Peter Convener: Lee Jones Convener: David Kibbe Bachman Identity & agency 2 are NOT health Mechanisms for EHR-HISP care specific, distributing trust bundling for MU2 attributes &11:00-12:00 bundles directories ARE PM Convener: Gary health care specific Convener: Rim Cothren Christensen Convener: Adrian 103 Gropper
    104. 104. Next Steps and Concluding RemarksClaudia WilliamsPaul Tuten
    105. 105. 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 -
    106. 106. Reminders• Don‘t forget to… • Sign-up for Trust Anchor Bundle Distribution Workgroup • Download presentation slides from Direct Project wiki • Complete evaluation forms - 106 -
    107. 107. Thanks! . - 107 -
    108. 108. Summary Slides
    109. 109. Organization Distribution* Trust Other Framework Health Provider Information Service Contractor Provider 7 (HISP) 2 Other Includes: 7 25 State HIE • Patient Privacy Rights Grantee • Provider 5 • Accreditation • Professional Society • Software Company 7 • Consumer AdvocateEHR Vendor • Standards Based 10 Community 8 12 Certificate Registration Authority Authority Federal Total number of forum participants: 69 Agency*Some participants represented more than one organization at the forum - 109 -
    110. 110. 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 -
    111. 111. 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 -
    112. 112. Key Takeaways – Breakout Sessions• A1 – “What do we do in the meantime?” – Lee Jones o 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” – David Kibbe o 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. - 112 -
    113. 113. Key Takeaways – Breakout Sessions• C1 – “Provider Directories and 360X Piloting” – Peter Bachman o 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 Cothren o 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. - 113 -
    114. 114. Key Takeaways – Breakout Sessions• 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 piece 2. 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 Gropper o 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. - 114 -
    115. 115. Milestones and Dates• 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. - 115 -
    116. 116. Action Items for the Community Item Proposed Due DateForm and participate in workgroup to December 2012automate trust bundle distributionForm and participate in workgroup onrefining ―package‖ of requirements to December 2012avoid/limit need for HISP to HISPagreementsForm and participate in workgroup on December 2012―what to do in the meantime‖Find pilot participants for the 360XProject that is supported by ONC Ongoing - 116 -
    117. 117. Reference
    118. 118. 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 -
    119. 119. Requirement vary across initiatives • 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 -
    120. 120. FBCA Certificate Types FPKI LOA Assurance CRL/Revocati 800-63-1 800-63-1 description on Token and ID Proofing Re-Key LOA Basic Basic level of risk and 24 hrs./24 hrs. LOA3 LOA3 compromise. 15 yrs. Likelihood of malicious access not high Medium Moderate risk and 24 hrs./18hrs. LOA3 LOA4 compromise – includes 9 yrs. monetary value or risk of fraud Medium High risk 24 hrs./18 hrs. LOA4 LOA4 Hardware 9 yrs. High Reserved for cross- 24 hrs./6 hrs. LOA4 LOA4 certification with 3 yrs. government entities. High Risk - 120 -
    121. 121. FBCA Information required Basic Medium HighIn ID number or One Federal Government-person account that could issued Picture I.D. or Real Act be used to ID, or two Non-Federal confirm name, Government I.D.s, one of which Same as Medium DoB, address and shall be a photo I.D. (e.g., other personal Drivers License) informationRemote ID number or One Federal Government- Not applicable for account that could issued Picture I.D. or Real Act HIGH be used to ID, or two Non-Federal confirm name, Government I.D.s, one of which DoB, address and other personal shall be a photo I.D. (e.g., information Drivers License) and Antecedent shared attributes or secrets from previous in-person event - 121 -
    122. 122. 800-63-1 Required Information Level 2 Level 3 Level 4 In Possession of valid current Level 2 plus Level 3 plus validated second person primary Government Picture •ID must be government ID or a validated ID verified financial account number. • applicant‘s picture, and Note: utility account • either address of record or information not acceptable for nationality of record LOA4 (e.g. driver‘s license or passport) Remote • Possession of a valid Same as Not applicable for LOA4 Government ID (e.g. a Level 2 but driver‘s license or passport) confirmation number and via records of • Financial account number both (e.g., checking account, numbers. savings account, loan or credit card) or utility account number with confirmation via records of either number. - 122 -