Stream: CARIN IG for Blue Button®
Topic: Personal representative business rules
Ryan Howells (Aug 26 2020 at 18:40):
We are getting a number of questions about how to handle the CMS requirement that requires access not only by the member but by the member's "personal representative" as defined by HIPAA. From the CMS rule, "Per the HIPAA privacy regulations at 45 CFR 164.502(g), a
personal representative is someone authorized under state or other applicable law to act on behalf of the individual in making health care related decisions (such as a parent, guardian, or person with a medical power of attorney)". Also here: https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html
Question: Since SMART only supports one identity and not multiple, how would access be granted to a member's personal representative? Would the member need to request access and then delegate that access in the app to the member's personal representative or could access be granted to the member's personal representative via the member's credentials during the authorization process?
In addition, we're hearing payers have their business rules built into their portal related to minor access, 42 CFR Part 2 data, personal representatives, etc. That means they would have to duplicate or extract their business rules from their portal to handle API access via SMART. I'm curious how payers are handling these two topics and what solutions may be available that we can point payers to. Copying others who may have already solved for this. @Josh Mandel @Isaac Vetter @Jenni Syed @John Moehrke
Jenni Syed (Aug 26 2020 at 18:50):
In our system, the patient designates their authorized representatives today, and we track that. They will get sign ons that identify them, and during authentication our server looks up who they are authorized to access. They're presented an authorization screen that list all patients they're handing over data for to the app (if using "user/" scopes) or to select from (for patient/ scopes). I showed some of these examples during the ONC Tech Forum also
Josh Mandel (Aug 26 2020 at 18:50):
I'm not sure what you mean when you say that "SMART only supports one identity" -- but the delegation question you are asking applies just as well to EHR systems today, since under hipaa, patients can delegate sharing decisions to an authorized representative.
Jenni Syed (Aug 26 2020 at 18:52):
As to "minors" - we handle the "aging out" as well as emancipation workflows automatically - the auth rep automatically loses access until the patient grants access again. In addition, for state law, we restrict what data the parent (for example) may have access to. Biggest example of this is sexual health data is typically protected for teens/within a certain age range.
Josh Mandel (Aug 26 2020 at 18:52):
And generally we have seen this kind of delegation happening outside of the portal environment -- but whether it happens through an automated portal interaction or whether it happens through a phone call, either way this is outside the scope of the SMART API. With SMART, some user who has access to data (e.g., a patient or guardian or authorized representative) he is able to share those data with an app.
Josh Mandel (Aug 26 2020 at 18:53):
I don't know what you mean by delegating access "in the app" @Ryan Howells ; this piece doesn't make sense to me, since the authorization protocol is upstream of what happens in the app.
Jenni Syed (Aug 26 2020 at 18:53):
If you're referring to the fhirUser reference in SMART - this is why we use "Person" for patient relationships when user scopes are involved - because it's not a Patient, and it's not a single RelatedPerson.
Josh Mandel (Aug 26 2020 at 18:54):
(@Jenni Syed I agree 100% with everything you've said here. As far as I am aware, CARIN's Blue Button IG is focused on patient level scopes and not users scopes.)
Josh Mandel (Aug 26 2020 at 18:57):
Honestly I don't think there is much to say about this in the blue button guide; this is not a unique problem about payer data, and for a CARIN blue button IG, it makes more sense to focus on the data profiles -- i.e. the pieces that are different from what the SMART App Launch IG covers. US Core is a good analogy.
Ryan Howells (Aug 26 2020 at 18:59):
We aren't planning on putting any guidance in the IG about this. It's a question we are getting and want to be responsive with industry best practices via email and other methods.
Ryan Howells (Aug 26 2020 at 19:03):
Delegating access in the app meant after the authorization process has occurred with the data holder and the member has access to the data within their app, the member would then use functionality within the app to delegate access to another individual. In other words, personal representative access would happen outside of and after the initial member authorization event.
John Moehrke (Aug 26 2020 at 19:17):
I agree with Jenni. This is predominantly handled outside of the specific flows of SMART. There would need to be some patient driven ceremony where the delegated rights are captured (aka, authorization or consent depending on what terms of art you prefer). The Ceremony is either the OAuth authorization workflow does this binding of the delegate user to the patient delegated access; and/or a FHIR Consent Resource would hold this binding of the delegated user with the delegated rights given by the patient. The workgroup focused on Consent has tried to get a set of people to work on this profile of Consent, but have not yet gotten interest in that profiling effort. We think that Consent can do this, and have some examples, but not a formal use-case analysis with implementation guide like instructions.
John Moehrke (Aug 26 2020 at 19:19):
this tends to be an organizations internal concern, so is not important to have an interoperable specification for it. Either you have captured delegation authority, or you have not; driving authorization policy, or deny access. Exposing the policy is a nice theory, but not important to be in interoperable form.
Ryan Howells (Aug 26 2020 at 19:25):
Thanks all. This is helpful. We have let them know previously this would need to happen outside of SMART and the business rules need to be an internal payer's concern so it's nice to get that confirmation. I'm tagging a few payers to see if this helps answer their questions or to correct anything I may have misstated. @Jason Teeple @Amol Vyas @josh lamb @Cille Kissel Watkins
Bhanu Vemuri (Aug 26 2020 at 21:19):
Most of the payers currently receive authorization to disclose data through paper form (below is the link for a reference). Authorization is either all or only certain specific data segments. Authorization will also have expiration date. Challenge that we have is converting the information managed in paper into structured format for API 's to use for validation and build response with data segments that authorized.
Josh Mandel (Aug 26 2020 at 21:41):
https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/personal-representatives/index.html has good background on the general premise of putting somebody in charge of decisions including data sharing decisions.
Ryan Howells (Aug 27 2020 at 01:37):
Let's hope @Bhanu Vemuri that OCR comes out with guidance in the near future that says using the SMART OAuth process would qualify as being an acceptable method for getting a member's authorization rather than only accepting a member's written authorization.
Josh Mandel (Aug 27 2020 at 02:26):
Re: request to share data (with an app): this is already an electronic signature and certainly complies with OCR guidance -- as implemented by EHR vendors today. Note that the OAuth dance is suitable for sharing data with software applications, but not with individual people.
Josh Mandel (Aug 27 2020 at 02:27):
There's some conflation in your comment above Ryan.
Jason Teeple (Aug 27 2020 at 10:45):
Thanks for providing some perspective on the topic. Payers most likely have varying levels of sophistication on handling authorization and personal representatives. Where there may be a perceived gap is around handling a personal representative in the JWT. I agree that authorization is handled outside of the SMART pattern, my question is around communicating the personal representative and the in the "patient" in the JWT. The use-cases I have seen and describe above by @Jenni Syed all revolve around EHR patterns, not payers.
Michele Mottini (Aug 27 2020 at 11:58):
A payer can do the same thing an EHR does, can'it it? The personal representative log-in and then select the represented person as the one to return the data of - and the SMART flow returns the FHIR patient id of the represented person - ie I log in and then select my minor child
Michele Mottini (Aug 27 2020 at 11:59):
(Note that the access token don't have to be a JWT, it is just an opaque string for the client)
Michele Mottini (Aug 27 2020 at 12:11):
(...that also means that you can put whatever information your server needs in it - like who logged in on behalf of who, so that the server can use that information to figure out which resources are accessible)
Jason Teeple (Aug 27 2020 at 14:32):
Michele Mottini said:
A payer can do the same thing an EHR does, can'it it? The personal representative log-in and then select the represented person as the one to return the data of - and the SMART flow returns the FHIR patient id of the represented person - ie I log in and then select my minor child
It depends...
Keeping in mind every Payer is different. You are assuming a few concepts:
- there is a process in place to receive the consent document and convert the value (assign person X personal rep for patient Y)
- payers assign a new identity for the personal representative
- the new personal rep identity is aligned to the patient identity
- there is a log-in/presentation for selecting a represented patient
While I can't speak for all payers, but based on conversations with some colleagues, I don't think the assumptions you are using are universal.
Michele Mottini (Aug 27 2020 at 14:46):
Sure, but none of those things have anything to do with the CARIN BB profile or SMART auth - they are internal things each payer would have to figure out (in the exact same way each EHR vendor and provider had to figure out)
Jason Teeple (Aug 27 2020 at 15:10):
I agree that CARIN BB Profile should not solve the problem. Though I think it is fair to point out that Payers cannot do the same thing as EHR vendors 100% of the time. Without having the full background, was SMART developed with Payers and personal representatives in mind or primarily built for EHR concepts?
Michele Mottini (Aug 27 2020 at 15:20):
I don't understand. SMART has very little to say or do with personal representative (from EHR, payers or anywhere else) - the only thing it specifies is how to return a FHIR patient id to the client and permission scopes, that are very generic.
Is there something specific you'd like to work differently?
Jason Teeple (Aug 27 2020 at 17:17):
Maybe this is my disconnect without having a full background - how does SMART return the Patient ID AND the Personal Representative ID? All I am saying is that assuming there is a payer process in place to seamlessly link Patient and Personal Rep is a bad assumption. The payer process may be broken; just trying to relay the concerns I have heard. Every Payer has a different process and it may not be automated or easily replicable.
Josh Mandel (Aug 27 2020 at 18:00):
The patient ID is part of the access token response (patient property). Apps can also request login information (via the fhirUser scope) and if granted, this information is shared as a fhirUser claim within the id_token property of the access token response. There's no explicit statement like "Person X is the personal representative of Person Y"; rather, we say to an app: "records for Person Y have been shared with your app; the user Person X is the one who shared them." Sometimes X==Y. The SMART protocol doesn't really care.
Pat Taylor (Aug 27 2020 at 22:33):
A document has been written using Personas and Patient Stories as a mechanism to describe how payers administer scenarios such as this. How a payer handles personal representatives would be outside of the SMART authorization and authentication interaction.
Other scenarios the document speaks to are:
· Data payers send to the apps will be filtered in alignment with HIPAA and state requirements. As these business rules (e.g, when a child reaches the age of majority, or court ordered restrictions) are applied as filters, the apps will not be aware of when the results may change.
· Depending how a payer maintains a member's data, the app may or may not continue to receive data when a patient changes lines of business (e.g., transitioning from QHP to MA).
· The app will not receive CMS data from the payer if a patient moves between Medicare Advantage and CMS Medicare coverage.
The document is not exhaustive or intended to convey legal guidance. However, it is a way to convey how data would be provided in various real life situations.
BCBSA's recommendation is to include a summary of the document in the IG with a link to the full document. I'll work with @Ryan Howells to provide a copy of the document on the chat. @Amol Vyas
Ryan Howells (Aug 28 2020 at 15:33):
Josh Mandel said:
Re: request to share data (with an app): this is already an electronic signature and certainly complies with OCR guidance -- as implemented by EHR vendors today. '''
Josh Mandel When you say the OAuth dance is suitable for sharing data with software applications and complies with OCR guidance, do you have a link to the specific ONC guidance that discusses this? That would really help the payer community.
I fully recognize that's the way EHR vendors do it today and is the industry standard. I just wasn't aware OCR has officially weighed in that OAuth is an acceptable electronic signature, hence my question. It was my understanding we were still waiting for OCR to officially weigh in on that topic. I'm not sure if Steve Posnack weighs in here much, but it would be helpful to get his perspective.
Michele Mottini (Aug 28 2020 at 17:59):
do you have a link to the specific ONC guidance that discusses this
The ONC mandates the use of SMART / OAuth2 to access healthcare data from providers - it better comply..
Pat Taylor (Aug 29 2020 at 11:59):
@Ryan Howells Re"request to share data (with an app): this is already an electronic signature and certainly complies with OCR guidance" , a few weeks ago on a call with CMS you and I were on, they confirmed that OAuth is an acceptable electronic signature for a user to share data with an app; however, that is not the same as giving permission for the user to access another person's health care records. That is governed by HIPAA; payers have established processes to provide that permission to the user. It is outside of SMART / OAuth. @Bhanu Vemuri @Jason Teeple
Patrick Haren (Sep 08 2020 at 14:44):
Agree - i.e. we should be careful not to confuse existing (out-of-band) mechanisms that give someone power of attorney or a personal representative role, with the mechanisms for them (once having that authority) to then authorize an app, on their behalf, to access the data that they are responsible for.
Also, the topic of what data a personal rep is authorized to see (and, hence, what data an app can be authorized to access on their behalf) is also a separate issue. Existing regulations, such as HIPAA and mental health laws, dictate this. I think the personas mentioned could be a good mechanism to provide examples of these nuances, if treated separately from any design assumptions about authentication, authorization, etc.
Bhanu Vemuri (Sep 16 2020 at 14:04):
We plan to return "all" the Patient ID's that user have consent to request the data along with access token. Can someone provide guidance on access token is granted at user level/that particular session to allow that token to be used to request data for any one of the patients in list? or we have to provide unique access token for each patient that user authorized?
Michele Mottini (Sep 16 2020 at 14:16):
The client chose what it wants: if the client request patient access scopes (egpatient/*.read) and launch/patient the server must returns a single patient ID in the token response and an access token giving access to data of that patient. This is the most common scenario.
Michele Mottini (Sep 16 2020 at 14:17):
If the client request user access scopes (eg user/*.read) the server returns an access token giving access to all patients the user has access to, no patient ID and the server must support a 'give me all patients' search ([base]/Patient) that returns all patients the user have access to.
Bhanu Vemuri (Sep 16 2020 at 14:54):
Thanks @Michele Mottini . CARIN IG require payers to support patient scope only. No requirement about user scope. Below is the excerpt from IG and link.
"Data holders SHALL support the use of the launch/Patient scope. The use of the launch/Patient scope will make it clear to an application the patient context that must be used for the duration of the connection. The authorization sequence supports the ability for data holders to provide a patient selection widget that can be used to enable delegated access to member information."
http://build.fhir.org/ig/HL7/carin-bb/Background.html#the-carin-alliance
Michele Mottini (Sep 16 2020 at 15:00):
OK - that is the first scenario. To implement that you cannot 'return "all" the Patient ID's that user have consent to request the data along with access token.' - only a single patient
Josh Lamb (Sep 16 2020 at 15:38):
@Bhanu Vemuri the application will call your authorize endpoint when they need a new access token. You will only return access tokens scoped to a single fhir patient id.
Bhanu Vemuri (Sep 16 2020 at 16:16):
Thanks for additional clarification @josh lamb and @Michele Mottini . I did find it as conflicting to the personas that CARIN team provide for guidance. Below is the excerpt from it. Numerous other examples in the personas align to the below as well. Any thoughts on it?
"Patient Story #1: Bill uses an app that is registered with his insurance company to access claim information associated with his health insurance coverage. Bill wishes to access his wife’s data. Bill launches the app. The first time he uses the app, it redirects Bill to the insurance company’s authorization server which requests Bill’s credentials. Once the insurance company verifies Bill’s credentials, the app is then granted a token that is constrained to data Bill is authorized to access based on current policies & consents or selections Bill made as part of the OAuth flow. The app uses Bill’s token to access Ana’s data, the insurer’s server interprets the consent and authorizes the operation. The insurer’s server will return Ana’s data, removing the data associated with her behavioral health services as directed by their state’s privacy law."
Michele Mottini (Sep 16 2020 at 16:29):
Sorry, don't see what's conflicting. The server prompts Bill to select who to return the data about, he selects Ana, the app gets back Bill's token authorizing access to Ana data + Ana FHIR patient ID, app gets the data.
Ryan Howells (Sep 16 2020 at 16:40):
The key is the business rules regarding which person's data Bill gets to see (Ana or others) is behind the payor's firewall and independent of the authorization event. The personas document is not part of the IG but provides directional guidance for payors on how they might want to configure their business rules but it's merely directional guidance and is optional.
Bhanu Vemuri (Sep 16 2020 at 17:20):
Michele Mottini said:
Sorry, don't see what's conflicting. The server prompts Bill to select who to return the data about, he selects Ana, the app gets back Bill's token authorizing access to Ana data + Ana FHIR patient ID, app gets the data.
I assumed based on previous explanation, Access token is granted to the individual patient as part of initial authorization. In the example above it is initially for Bill to see his data. Bill have to request "new" access token for Ana data. Sorry If I confuse you more with it.
My intent is to know at a high level, access token that granted is for an individual or all that user have consent (example above - Bill and Ana).
Michele Mottini (Sep 16 2020 at 17:24):
The token MUST grant access to the selected patient data (Ana in that example), if the app requested a patient scope ideally it should grant access ONLY to that patient data, but a server is free to return a token with _more_ access than that (eg a token that can access both Bill and Ana data)
Last updated: Apr 12 2022 at 19:14 UTC
