Connecticut Ave NW, Washington, DC Direct Texting A Concept/Proposal from DirectTrust to In-Bundle HISPs and CAs Direct Messaging Direct Texting

Connecticut Ave NW, Washington, DC The basic idea To leverage DirectTrust’s security and trust infrastructure, and our national network, to provide open, standards-based, secure, and identity validated Direct texting. HISPs could offer Direct texting services to existing and new customers alongside their Direct messaging services. Anyone on the network could connect with anyone else on the network via Direct texting apps. DirectTrust would hold license to open technical specification for Direct texting, analogous to the Applicability Statement for Direct messaging. Other licensing arrangements to be considered. Direct Messaging Direct Texting

Connecticut Ave NW, Washington, DC Defining the smartphone texting markets Barriers to healthcare texting What the healthcare market needs The opportunity for the DirectTrust network How to accelerate process Next steps Outline Direct Messaging Direct Texting

Connecticut Ave NW, Washington, DC Provider to Provider: Texting between providers including Protected Health Information (PHI). Happens regularly; hospitals are trying to prohibit for compliance reasons. 2.Hospital to Provider: Aka paging, this has been used for a long time. Hospitals and providers would prefer to avoid dedicated pagers, and have the ability to include PHI information in such texts (currently not allowed). 3.Provider to Patient: Texting between providers and patients. Widespread for appointment reminders. Increasing, especially with younger patients, for other purposes. The three use cases

Connecticut Ave NW, Washington, DC No guarantee of privacy: Texts within iOS, Android and BBM are encrypted, but cross platform texts use SMS network and there is no guarantee that they will be encrypted at carriers. 2.Complete lack of auditability: End to end encryption within the iOS, Android and BBM networks prevent audits. The SMS networks do not have any easy auditability. 3.Standards Vacuum: Closest spec (XMPP/Jabber/XCP) has ‘perfect forward security’ model (no auditability) or no end user PKI credentials. 4.Lack of reliability: Cross platform texts, or hospital paging, lack guaranteed delivery. 2-5% of all texts are lost. 5.Proprietary Silos: Private app-based solutions solving some of the above exist. They are siloed, centralized services. They do not inter-operate and either lack end to end encryption or auditability. Also lack strong identity proofing and authentication. Providers unlikely to use different apps for texting different providers or patients. The current barriers

Connecticut Ave NW, Washington, DC An open standard for healthcare texting stewarded by a trusted and competent neutral organization. 2.Interoperable end to end privacy. Implication of a PKI solution is unavoidable. 3.The solution must have end to end privacy WITH auditability AND WITH strong identity proofing and authentication. 4.The solution must have guaranteed delivery with return receipts. 5.The solution must work on any platform – TODAY, without persuading Apple, Google, BlackBerry, Microsoft, etc. to endorse standard. The solution needed

Connecticut Ave NW, Washington, DC DirectTrust is a trusted organization capable of stewarding the healthcare texting standard in partnership with ?? There are two aspects to any such standard: 1.The operational standards, e.g. Certificate Policy, ID proofing, accreditation via EHNAC-DirectTrust. 2.The technical specs. DirectTrust has already done all the work on the operational standards. DirectTrust accreditation and credentials can be reused by a PKI based healthcare texting standard. Leveraging the work already done by DirectTrust and its members is key to this opportunity’s success. DirectTrust in-bundle HISPs are ideally positioned to expand their service offerings to include Direct secure texting and paging, starting with existing customer base of hospitals, health systems, medical practices, etc. The DirectTrust opportunity

Connecticut Ave NW, Washington, DC Part of incubator set up with (unusual) business model: Identify market vacuum, invent, build proof of concept, license/sell intellectual property and s/w Not a traditional software or SAAS vendor No direct sales to enterprises or consumers Invest little… Sell for little more… Status of technology relevant to this conversation: Owns or licenses relevant intellectual property Well developed alpha code (ready to show customers) Exploring various licensing/sale options E.g. make SPEC open; license app and server software 3pTALK Background

Connecticut Ave NW, Washington, DC Capabilities Walk Through 1.Initial multifactor authentication to 3pTALK App & Switch 2.User to user secure messaging 3.Enterprise to user messaging (aka paging) 4.Focus on graphical and digital signatures 5.Site and user mutual authentication and light federation 6.Audit SWITCH Audit Server Admin Server Org Interface CA

Connecticut Ave NW, Washington, DC Back Up – More Info If you want to try app, we will set up an account on our guest network. Please contact: – Ravi Ganesan, – Note we currently support iOS and Android. BlackBerry is supported via Android side loading (no PUSH notifications). Or, the screen shots that follow give you a taste of the product. – Messaging types – CONFIRM, QUERY, OPTION and INFORM. – OTP and Federation Lite flow – Sample Org Interface screen shot – Sample Audit System screen shot You can also see videos at

Connecticut Ave NW, Washington, DC Initial Two Factor Authentication SWITCH OOBA OOBA could be replaced by existing multifactor authenticator, or trusted credential broker for initial authentication. Note step shown on right would usually not be needed. At end of login user has a PKI credential. The CA could be co- resident/external. CA

Connecticut Ave NW, Washington, DC P2P Messaging – Privacy + Auditability SWITCH Process Alice sends Bob message encrypted with session key. Session key enveloped with Bob’s public key. Session key enveloped with Audit Service’s public key. If first communication, Bob is asked if he wants to accept messages from Alice. If he says yes, then he and Alice share session key for future communication. Audit server retrieves encrypted messages. Can provide data to authorized party. Audit Server Benefits Privacy: True end to end encryption; Messages opaque to SWITCH. Auditability: Audit server, which could be a 3 rd Party middleman, similar to a federation anonymizer, can provide message if required. Admin Server

Connecticut Ave NW, Washington, DC Secure Enterprise Paging Web based interface for an enterprise back office to message users (aka paging). A hospital that has deployed pagers to their medical staff can use the 3pTALK app instead. Unlike SMS, 3pTALK has guaranteed delivery and is secure. Also saves paging costs. Ability to do group messaging, pre-scheduled and/or recurring messaging. Goal is to get these APIs embedded in systems like EHRs, or integrated with banking systems. SWITCH Audit Server Admin Server Org Interface

Connecticut Ave NW, Washington, DC Message Types Supports five message types for both P2P and enterprise to user. CHAT: Familiar SMS/text metaphor. SIGN: To be discussed later. INFORM: Informational one-way; e.g. “remember to take your medication”, or “your account balance has insufficient funds”. CONFIRM: Requires yes/no answer; e.g. “Did you do your cardio today?”, or “Did you schedule a wire of $10,000 to Count Dracula”. QUERY: Allows free form response; e.g. “what is your blood pressure today?”. OPTION: Same as QUERY except sender provides multiple choices. Messaging, transaction authentication, signing and more…

Connecticut Ave NW, Washington, DC Graphical and Digital Signatures End users who get a signature request, simply perform a graphical signature. Behind the scenes, an X.509 compliant digital signature is being generated. Recipient has both graphical and digital signature, and messaging logs at audit server, to gain a high degree of non-repudiation and evidence if needed.

Connecticut Ave NW, Washington, DC Multifactor Authentication Process – User enters ID at Relying Party (RP) – RP sends ID to SWITCH – SWITCH computes OATH OTP and sends OTP and RP Name to app – User displays OTP at app, and enters OTP at RP – RP asks SWITCH to verify Benefits – Super simple “zero crypto” interface for RPs – No seeds at app or RP SWITCH Relying Party

Connecticut Ave NW, Washington, DC Back Up – More Info If you want to try app, we will set up an account on our guest network. Please contact: – Ravi Ganesan, – Note we currently support iOS and Android. BlackBerry is supported via Android side loading (no PUSH notifications). Or, the screen shots that follow give you a taste of the product. – Messaging types – CONFIRM, QUERY, OPTION and INFORM. – OTP and Federation Lite flow – Sample Org Interface screen shot – Sample Audit System screen shot You can also see videos at

Connecticut Ave NW, Washington, DC Messaging - CONFIRM

Connecticut Ave NW, Washington, DC Messaging - QUERY

Connecticut Ave NW, Washington, DC Messaging - OPTION

Connecticut Ave NW, Washington, DC Messaging - INFORM

Connecticut Ave NW, Washington, DC Settings and View Certificate Various settings can be managed here. User views their certificate. Only place in product that our “invisible PKI” is visible!

Connecticut Ave NW, Washington, DC SWITCH Relying Party Multifactor Authentication Step 1: User enters ID into web site.

Connecticut Ave NW, Washington, DC Multifactor Authentication Step 2: RP passes ID to SWITCH. Pushes OTP to app. User enters in web site.

Connecticut Ave NW, Washington, DC SWITCH Relying Party Multifactor Authentication Step 3: RP sends SWITCH OTP. If positive response, user is logged in successfully.

Connecticut Ave NW, Washington, DC Screen shot from Org Interface

Connecticut Ave NW, Washington, DC Screen shot from Audit System