Use Case:

        Alice has decided to choose a new PCP and wants to electronically schedule her first appointment and complete the initial patient registration forms.

        Steps:

                    Alice needs to create a new account on the practice's patient portal.

                    The patient portal provides Alice with the practice's privacy policy (basic TPO use only as defined in 45 CFR 164.506) to review.

                    The patient portal requests that Alice acknowledges she has received the practice privacy policy to use her information for TPO. (i.e. the basic implied consent)

                    Alice chooses Dr. Bob as the doctor she want to see.

                    Alice schedules an appointment.

                    Alice then elects to complete the new patient registration forms online.



        Assumptions: (These may need to be revised)

                    The cloud based PHR system provides a Authentication service, oAuth 2 service with UMA profiles.

                    The Practice's Patient portal provides a Authentication service, oAuth 2 service with UMA profiles.

                    The local PHR application has its own local user access controls and supports only the basic oAuth 2 features required to interact with the Practice Patient Portal.



        Questions:

                    Client one: If Alice has chosen a cloud based PHR that already has an established trust:

                                What are the credentialing requirements to create Alice's account?

                                            Note that ONC"s Ten year interop roadmap refer's to NIST SP 800-63-2 and OMB M-040-04 and is implying level 2 or 3 levels of assurance (LOA). (see pp 59)

                                Are there two or three consent profiles?

                                            One for Alice's PHR defining what to share with the Practice?

                                            One for the Practice defining what is to be shared with Alice's PHR?

                                            One for Alice at the Practice portal defining what the Portal (or Practice?) is to be shared?

                                How is the initial implied consent for TPO electronically presented, stored and accessed?

                                            How is this consent profile used by the practice's internal HIT systems? (if at all)

                    Client Two: If Alice has chosen a local application based PHR that has not established trust with the practice's portal:

                                What are the credentialing requirements to create Alice's account?

                                            Note that ONC"s Ten year interop roadmap refer's to NIST SP 800-63-2 and OMB M-040-04 and is implying level 2 or 3 levels of assurance (LOA). (see pp 59)

                                Are there two or three consent profiles?

                                            Is there a profile for Alice's PHR defining what to share with the Practice?

                                            One for the Practice defining what is to be shared with Alice's PHR?

                                            One for Alice at the Practice portal defining what the Portal (or Practice?) is to be shared?

                                How is the initial implied consent for TPO electronically presented, stored and accessed?

                                            How is this consent profile used by the practice's internal HIT systems? (if at all)

                                            How is this consent profiled used by the PHR and the Practice's Patient portal?

Follow on Discussion summary:

Summary Alice makes an appointment with a new doctor. When she arrives at the doctor’s office, she links her record system with her doctor’s record system. She receives an examination, and a record of that examination is recorded in both systems.

The following terminology is used to describe people in this use case:

Alice - Alice is an example patient who consumes healthcare services

Primary Care Provider (PCP) - a health care practitioner who will see Alice on a regular basis for common medical concerns The following terminology is used to describe systems in this use case:

Protected Resource (PR) - information for which Alice maintains access control policies

Authorization Server (AS) - system which implements Alice’s access control policies over her protected resources

Client - system which is used to request access to a protected resource from an authorization server

Personal Health Record (PHR) - a private cloud-based information system which tracks Alice’s medical information for her. A PHR may serve as a PR, AS, client, or all three.

Electronic Health Record (EHR) - an enterprise cloud-based information system which tracks many patients’ medical information. Also known as Certified EHR Technology or CEHRT. An EHR may serve as a PR, AS, client, or all three. Use Case 1. Alice has an existing relationship with a PHR. She has provided the PHR with several protected resources including basic demographics, insurance information, active medications and a list of chronic problems. Identity proofing at the PHR consisted of a credit card transaction and email verification. The PHR has optional two-factor authentication using SMS. 2. Alice calls a PCP’s office over the phone to enroll and book her first appointment. a. The PCP’s office creates a patient record for Alice in their EHR system and schedules an appointment for her. This patient record is a protected resource. 3. Alice arrives for her scheduled appointment and registers at the front desk a. She is identity proofed using her driver’s license and insurance card, which are scanned. The images are stored in the office’s EHR system. b. As a result of this identity proofing, Alice’s record is now marked as “known to the practice.” c. She tells the registration desk which PHR she uses and the email address she uses to identify herself in that system. d. The doctor’s office sends a verification email to Alice through her PHR. e. Alice completes the email verification using her phone, and can now log in to view her protected resources in the PCP’s EHR at any time using her PHR to authenticate. f. Alice sets an authorization policy on her PHR, (which acts as an authorization server) to update her PCP’s EHR (which acts as a client) one time with some of her protected resources such as basic demographics, insurance information, active medications and list of chronic problems. g. Alice electronically consents to her PCP office’s privacy statement. She sets an authorization policy on the PCP’s EHR (which acts as an authorization server) to allow the record of that consent (which is a protected resource) to be recorded in her PHR (which is acting as a client). 4. While she is in the waiting room, Alice authorizes her PHR (which acts as an authorization server) to update her PCP’s EHR (which acts as a client) every time the PHR has new medical information (this information is a protected resource) about Alice. Alice then authorizes her PCP’s EHR (which now acts as an authorization server) to update her PHR (which now acts as a client) every time the PCP’s EHR has new medical information (this information is a protected resource) about Alice. Since both systems use the FHIR API, this synchronous bidirectional information transfer is simple and seamless. 5. Alice is taken to the examination room a. Alice’s PCP accepts the updates that Alice pushed from her PHR. b. Alice’s PCP conducts a physical examination and records the results in the EHR system. c. Alice’s PCP orders lab tests for a CMP, CBC, Lipid Panel and liver Panel through the EHR system. d. Alice’s PCP tells her that patient education materials and pre-lab fasting instructions available on the EHR system. 6. Alice goes home and receives notification that her information has been updated in her PHR and her PCP’s EHR system. List Additions: [adding the HEART list back on the thread]

While this is a real threat, I think this speaks more to a need for IdPs to allow log-in and verification through means that aren’t susceptible to kiosk-based attacks like this. Having an out of band verifier, like an OTP token, U2F crypto challenge, or colluding app on Alice’s phone all make the phishing the password less detrimental. If nothing else, her IdP can notice that Alice is logging on with an unfamiliar computer and require higher levels of authentication, all of which she’d be familiar with.

That said, in HEART, we might be able to (or might need to) come up with standardized means for binding the IdP account while at an untrusted network environment (the doctor’s office). The simple approach is of course to just have Alice log in, but perhaps there are other ceremonies that we can count on. Round-tripping the email address isn’t going to give a very strong binding to an IdP, but maybe there’s something we can do there. Just thinking off the cuff, I can think of a flow that’s reminiscent of something we did at MITRE years ago with an OAuth 1.0 client that worked over email:

• Alice shows up at the doc’s office
• Alice’s doc logs in and opens up Alice’s medical record on a kiosk
• Alice enters her email address into a form on this doc-authenticated page
• Doc’s computers use this email address to do a webfinger lookup to find Alice’s IdP
• Doc’s computers register with the IdP and start an authentication transaction but don’t open a local browser
• Instead, Doc’s computers send Alice an email with the fully-kitted authorization URL
• Alice gets the email and opens up the link
• Alice is presented with her own IdP’s regular authorization screen (she’s probably already logged in on her device)
• Alice authorizes the Doc’s computers to access her identity information
• Alice is sent to the redirect URI, which is back on the Doc’s system
• This redirect URI could either (a) automatically message the waiting kiosk application through a trusted back-channel that the authentication has taken place, using the ‘state’ value as a secure key between them or (b) display a short code for Alice to enter into the kiosk. Remember, the redirect URI’s contents are rendered on Alice’s device.

In the future, Alice can log in from any device she wants to using her IdP at the Doc’s system, since it’s been strongly bound by the ceremony.

— Justin

On Jun 15, 2015, at 5:12 PM, Sarah Squire sarah@engageidentity.com wrote:

I actually like the email address verification not because it's a verification, but because it's a better and more secure user experience. If Alice has to log into her IdP at the registration desk, she has to remember her password (unlikely), then type it into a kiosk that might have a keylogger, or where her keystrokes might be captured by a camera. Alternatively, if the IdP binding is done via email verification, she can log in on her phone, which, if it doesn't already have an open session, probably has her password vault, and even if it doesn't, at least she's typing into her own device rather than a kiosk.

Sarah Squire Engage Identity http://engageidentity.com

On Mon, Jun 15, 2015 at 1:09 PM, Justin Richer jricher@mit.edu wrote: I’ve made this remark on a few of the other use cases, too: I think that we ought to be concentrating on making use of digital federated identities instead of inventing a thousand and one “digital proof” mechanisms like the email address verification listed here. It’s not really central to the use case’s goals so it’s more decoration to the story than anything, but I still wouldn’t want us to put a lot of effort into codifying little workarounds like this.