Stream: smart/health-cards
Topic: Getting 403 in user accounts page
Cibi Siddharth (Apr 14 2021 at 07:41):
Need to get the Secret key for the user and provider account we created. When we tried to access the user accounts page we are getting 403 Access Forbidden. So we cant able to get the secret key to generate the access token.
user-account-url: https://cernercentral.com/user-accounts(403 Access Forbidden)
cc: @Suprakash Maity @Santosh Jami @Rohit Bankia
Santosh Jami (Apr 14 2021 at 08:21):
tagging @Michael Turman @Joe Rattazzi
Santosh Jami (Apr 14 2021 at 12:01):
Joe Rattazzi (Apr 14 2021 at 12:58):
Hi. Can you share the system account id, please?
Edit: for this specific issue, we want to resolve this via Private message or email (to avoid any private app information from being posted)
Joe Rattazzi (Apr 14 2021 at 13:00):
As a note, for the HealthCards integration, the specification only supports Patient access workflows (where the patient directly authenticates). System accounts (like you have listed) can't be used to generate the OAuth token
Matt Printz (Apr 14 2021 at 13:32):
Joe Rattazzi said:
As a note, for the HealthCards integration, the specification only supports Patient access workflows (where the patient directly authenticates). System accounts (like you have listed) can't be used to generate the OAuth token
Is this set in stone? One of our main concerns is around adoption, and we've found that small "snags" in the workflow like this can cause a good amount of users to give up. Either they don't know/can't find their password, or just don't want to bother, especially given the hesitancy out there on this topic, having it "just work, and work well" might make the difference.
Joe Rattazzi (Apr 14 2021 at 13:38):
That's a great question - from my understanding, the goal of the project is for the patient to be able to integrate with their different hospitals/clinics/etc. to personally retrieve their health cards.
This might be a question we need to direct to the larger group in the smart/internal-health-cards chats. If you're not already in that chat, I'm not sure if I have the power to add you or if we need someone like @Josh Mandel to invite folks in
Matt Printz (Apr 14 2021 at 13:41):
I am not in that chat and am not finding it to join. Would be happy to join.
Joe Rattazzi (Apr 14 2021 at 13:42):
I think I got you added, so hopefully that worked
Josh Mandel (Apr 14 2021 at 13:51):
SMART Health Cards is focused on sharing data with consumers. When a consumer wants to connect an app of their choice to their health records inside of a clinical provider system, we use the SMART App Launch to accomplish this; the pattern is based on consumer approval and right of access, rather than business to business trust.
Josh Mandel (Apr 14 2021 at 13:52):
Let's keep this conversation here, in public!
Josh Mandel (Apr 14 2021 at 13:55):
It's always possible for a clinical provider to enable business to business trust through use of technologies like SMART Backend Services, but the details of those kinds of arrangements are out of scope for the scenarios we established for this connectathon.
(On a practical level, I hope it is very clear what that would look like -- e.g., a somehow-authorized app could use Backend Services to obtain an access token with scopes like system/patient.read system/Immunization.read, and then could invoke an issuance operation just like we do for consumer authorized apps.)
Matt Printz (Apr 14 2021 at 13:59):
Is there a potential middle ground here? We are a "connected health" company, and as such, our users authorize us to and have the expectation that we will collect their medical information once they authorize the connection one time. We only collect the information on behalf of the users, to be viewed/used at the users' sole discretion.
Being able to pull in the SHC info along with, say, the rest of the Cerner EHR data could drive adoption of the use, as it would just show up in the app as ready to use and wouldn't require an additional, extra flow that might discourage adoption.
Josh Mandel (Apr 14 2021 at 14:15):
What you are describing is the crux of interoperability! And (...to be a bit provocative here -- please understand that I totally know where you're coming from!) from a certain vantage point, what you are asking for is that the ecosystem simply trust you because you're going to do the right thing. I'm not saying that's a bad idea; I am only saying it does not scale well, and does not build an end-to-end model of consumer trust.
Josh Mandel (Apr 14 2021 at 14:16):
If you can negotiate this level of trust with Cerner and with healthcare providers, the APIs are there to support you. But in my experience this negotiation is extremely challenging, slow, and (for some good reasons) limited; as such, it is safer to fall back on a consumer's right to access, which trumps these kinds of organizational trust decisions.
Josh Mandel (Apr 14 2021 at 14:18):
The forces of HIT Certification rules, HIPAA right of access, and Information Blocking prohibitions are all aligned to ensure the consumers have this kind of choice, but the alignment breaks down (i.e., you no longer get these guarantees) as soon as the trust decisions move into the hands of a covered entity.
Matt Printz (Apr 14 2021 at 14:34):
I understand all that and strongly sympathize. The place where I'm getting a bit stuck thinking it through is: Say we (my company) have authorization to pull EHRs that include immunization information, and the customer requests that we pull their data: that immunization info is already going to be in our system.
In such a case, I'm not sure if there is a greater risk for a immunization SHC to be pulled over as well, without requiring the user to OAuth all over again. We already have the information, we just don't have the SHARABLE information.
I would, of course, not want to be able to pull information that we are not authorized to have via SHC, but if we are authorized, allowing the automatic sharing of the SHC as an extension of EHRs make sense to me, if there is not a technical reason why this couldn't be done.
Josh Mandel (Apr 14 2021 at 14:35):
I would say that's a good topic of discussion for you to work out with the vendors where you are currently authorized to pull data, building on whatever mechanism you're using there. Again, not saying this is a bad idea ; just saying this is out of scope for the scenarios we are focused on here.
Josh Mandel (Apr 14 2021 at 14:36):
To be clear: if you can get buy-in to work on this as an additional scenario beyond the ones that we drafted for the connect-a-thon, I would say it's worth exploring. I just wanted to explain why it is outside of our area of focus.
Matt Printz (Apr 14 2021 at 14:36):
I agree. (Which is why I originally tried to move it out of the Connectathon thread)
Josh Mandel (Apr 14 2021 at 14:39):
Not a good topic for the "internal" chat (which is focused on implementers participating in VCI).
It seems like a fine thing to discuss in this thread, or else I'd maybe bring this up in Cerner's forums.
Michael Turman (Apr 14 2021 at 15:11):
Understand your position, Matt. We have to be pragmatic about our scope decisions - right now the priority is on consumer driven workflows. We should continue the conversation in the space of 'connected health' and the kinds of patterns systems like yours want to see related to verified health credentials.
Matt Printz (Apr 14 2021 at 15:16):
Sure. I'm not expecting the change to be done today... but I would like to continue the conversation.
Last updated: Apr 12 2022 at 19:14 UTC
