Individual Cerner Hospitals

215 views
Skip to first unread message

Vishal Goel

unread,
Mar 18, 2019, 5:06:11 PM3/18/19
to cerner-fhir...@googlegroups.com

Background: We have an app registered in the Cerner sandbox. I'd like to get provisioned for access by individual Cerner hospitals. 


Advice I've been given so far: A healthcare facility can log a simple service request to Cerner using our general support portal to request that your app be provisioned for access.


Issue Explanation: I've been calling Cerner hospitals individually to get provisioned for access. However, all the hospital staff I've spoken to are confused about my request. I usually get transferred to various departments, and even the technical support departments in the hospitals have been confused about the request. 


Questions

     - Do I speak with the hospital's IT department to make this request? Is there a specific name for the department that would understand this request? Or that interfaces with Cerner? 

     - What information do we give to the hospital, do we give them our unique "App Id" or "Client Id"? 

     - Can our app be provisioned for access even though it's in the sandbox and not production-ready? 

Denis Mulder

unread,
Mar 18, 2019, 5:36:54 PM3/18/19
to cerner-fhir...@googlegroups.com
Notwithstanding the right intent of Cerner, explained in other threads, this process simply does not work. Numerous posts like this demonstrate this. Especially, it does not work for mass consumer apps, as the vendor does not know upfront who will be the user, let alone which health care provider(s) they are using and which health care provider should give access to the app.
It would be much better if something similar to Epic would be implemented, where health care providers can give API usage consent to all apps registered through Epic and in this case Cerner. Of course the patient still has to authenticate with the health care provider through Oauth. 
That way, the app provider does not have to worry about registering with individual health care providers and the whole ecosystem (especially the patient) would benefit.

Denis.
--
You received this message because you are subscribed to the Google Groups "Cerner FHIR Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-devel...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/5fdb1326-3078-4c73-9755-4fe4bfa74de5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

kevin maloy

unread,
Mar 18, 2019, 5:47:03 PM3/18/19
to cerner-fhir...@googlegroups.com
If you feel strongly about this, you might want to take a look at and comment on the proposed rule that is making fhir happen (there is section on registering apps)  ...  




For more options, visit https://groups.google.com/d/optout.
--
mobile.

Vishal Goel

unread,
Mar 21, 2019, 3:49:04 PM3/21/19
to cerner-fhir...@googlegroups.com
I completely agree. But I don't know when Cerner will change their system. There's no public timeline, so it could be months or years, so in the meanwhile I have to work with what's available. 

Apple is the only one who can pull off calling 5K hospitals for whitelist, and smaller developers are not capable of putting in that grunt work alone. 


So far we have the list of hospital endpoints: https://github.com/cerner/ignite-endpoints/blob/master/dstu2-patient-endpoints.json

What we're missing is: 

- location of hospital/provider

- contact information of hospital/provider

- best department to contact within hospital/provider


Should we start collectively crowdsourcing location (city, state), contact information (phone, email), and the best department to contact within the hospital/provider? 

Adrian Gropper

unread,
Mar 21, 2019, 3:57:51 PM3/21/19
to Cerner FHIR Developers
YES!

Let's use Twitter for the crowdsourced list. Can someone suggest a #tag?

This, by the way is exactly what the draft NPRM is designed to avoid. Unfortunately, the NPRM regulations don't go into effect for 24 months after finality and that means end of 2021. How many of us on this list are willing to wait until then? Please send your comments about this to ONC and CMS. The deadline is May 3.

Adrian

On Thu, Mar 21, 2019 at 3:49 PM Vishal Goel <vis...@goels.us> wrote:
I completely agree. But I don't know when Cerner will change their system. There's no public timeline, so it could be months or years, so in the meanwhile I have to work with what's available. 

Apple is the only one who can pull off calling 5K hospitals for whitelist, and smaller developers are not capable of putting in that grunt work alone. 


Should we start collectively crowdsourcing location (city, state) of hospital/provider, contact information (phone, email), best department to contact within that hospital/provider? 

--
You received this message because you are subscribed to the Google Groups "Cerner FHIR Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-devel...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.

L.H.D. Mulder

unread,
Mar 21, 2019, 4:59:46 PM3/21/19
to 'Denis Mulder' via Cerner FHIR Developers
It seems to me that the NPRM regulations only put requirements on API Technology Suppliers (they should enable app registration, but towards what end??) and not on API Data Providers. 

Specifically, under VII.B.4.A STATUTORY INTERPRETATION AND API POLICY PRINCIPLES, pro-competitive, it states:

(i) "Moreover, health care providers should have the sole authority and autonomy to unilaterally permit third-party software developers to connect to the API technology they have acquired.”
This sentence goes completely against the idea that a patient should be the one who determines what happens with their data.

Sentence (i) is a fundamental problem. If every health care provider has to authorize every app, IT WILL NEVER WORK. Who would initialize this authorization process and when? 

The app provider? But in case of mass consumer apps, how does the app provider know upfront which health provider its customer (patient) is using? The app provider would have no choice but requesting authorization from every single health care provider.

The patient? But the process is supposed to be effortless for the patient.

The rule should be bolder. If the API Data Provider uses a certified system from an API Technology Supplier and a patient is authorized to access those data residing at the API Data Provider then an app registered with the API Technology Supplier that the patient is using should automatically be able to use the Data Provider’s API.

Thoughts?

Denis.



Vishal Goel

unread,
Mar 21, 2019, 5:03:28 PM3/21/19
to Cerner FHIR Developers
Let's do it! 

I'm already following you on on twitter at @agropper

Yeah exactly, I can't wait until the end of 2021 to start to take action on Cerner's hospitals


On Thursday, March 21, 2019 at 12:57:51 PM UTC-7, Adrian Gropper wrote:
YES!

Let's use Twitter for the crowdsourced list. Can someone suggest a #tag?

This, by the way is exactly what the draft NPRM is designed to avoid. Unfortunately, the NPRM regulations don't go into effect for 24 months after finality and that means end of 2021. How many of us on this list are willing to wait until then? Please send your comments about this to ONC and CMS. The deadline is May 3.

Adrian

On Thu, Mar 21, 2019 at 3:49 PM Vishal Goel <vis...@goels.us> wrote:
I completely agree. But I don't know when Cerner will change their system. There's no public timeline, so it could be months or years, so in the meanwhile I have to work with what's available. 

Apple is the only one who can pull off calling 5K hospitals for whitelist, and smaller developers are not capable of putting in that grunt work alone. 


Should we start collectively crowdsourcing location (city, state) of hospital/provider, contact information (phone, email), best department to contact within that hospital/provider? 

--
You received this message because you are subscribed to the Google Groups "Cerner FHIR Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsub...@googlegroups.com.

Adrian Gropper

unread,
Mar 21, 2019, 7:22:49 PM3/21/19
to cerner-fhir...@googlegroups.com
This is exactly why CMS Blue Button 2.0 is already headed to Dynamic Client Registration and the NPRM requests comment about DCR. 

For patient-directed access, the patient controls the “designee” but not the Client that the designee will use. The only party capable of registering a client with the patient’s hospital endpoint (whatever it is) is the designee. In other words, the patient has to trust the Designee, no the technology that the Designee chooses to use.

Therefore, under the proposed NPRM, DCR allows the Designee to register their Client without special effort. The patient uses their hospital portal credentials to specify the Designee without special effort. This leaves open the question of who hosts the Authorization Server.

In cases where the hospital allows the patient to use their portal credentials to designate the Authorization Server instead of the Designee, then the hospital no longer has to suffer the liability of running the Authorization Server. The patient gains the added convenience of dealing with all of their consent and authorization issues across various hospitals, payers, research biobanks, etc... in one place (the designated AS). It’s a win-win for “without special effort” all around.

The standard for separating the OAuth Authorization Server from the OAuth (FHIR) Resource Server is called UMA. UMA is currently linked to the NPRM via the Interoperability Standards Advisory. You can read more about this in my blog posts about comments to the NPRM. 

Adrian 


For more options, visit https://groups.google.com/d/optout.

Denis Mulder

unread,
Mar 22, 2019, 10:10:30 AM3/22/19
to cerner-fhir...@googlegroups.com
Hi Adrian,

Thanks for your response, but I am not sure I follow what you are writing. E.g you use the word “designee” as a key term, but it is hardly used or defined in the NPRM. Would a third party app provider be a “designee”?

I any case, I still don’t see how this NPRM, that seems to put requirements on API Technology Suppliers only, can take away the issue of individual API Data Providers (health care providers) having to bless individual app provider clients that a patient wishes to use. The NPRM even mentions this issue specifically as a goal!!: 
"Moreover, health care providers should have the sole authority and autonomy to unilaterally permit third-party software developers to connect to the API technology they have acquired.”

I am not sure how to comment on this fundamental issue of the NPRM and neither do I see how Dynamic Client Registration (DCR) will resolve this, unless such registration implies automatic authorization by the respective health care provider to permit the app developer to connect to their API. But DCR is with the API Technology Supplier and not with the API Data Provider. And automatic authorization to use the API deployed by the API Data Provider would be in contradiction with the quoted NPRM text above.

All in all, very unclear to me.

Denis.

Michele Mottini

unread,
Mar 22, 2019, 10:40:15 AM3/22/19
to Cerner FHIR Developers

"Moreover, health care providers should have the sole authority and autonomy to unilaterally permit third-party software developers to connect to the API technology they have acquired.”

I am not sure how to comment on this fundamental issue of the NPRM


Consider that (1) the NPRM  does not cover just patient-facing apps, but also provider facing ones - and for the latter it is surely true that the providers must be able to decide which app to enable; (2) even for patient facing app I don't know if requiring that providers relinquish all control and just accept whatever their technology vendor enable is gonna fly - for sure I don't see our own customers accepting that (we do both app and certified APIs - so we are on both sides of this)

I think the way forward (and we are going to comment along these lines) is that:

- the published end point list(s) include contact details for the provider (+ other info like addresses - to better identify them)

- API user can use that contact information to request enabling the app they are interested in (send an email basically)

- upon receiving such requests for patient -facing apps the providers have to enable them within a set time or being guilty of information blocking (and this last part is already in the proposed rules if I remember correctly)

  - Michele
   CareEvolution Inc

L.H.D. Mulder

unread,
Mar 22, 2019, 11:21:19 AM3/22/19
to 'Denis Mulder' via Cerner FHIR Developers
I honestly believe such process won’t work for mass consumer apps. The app provider simply does not know upfront which health system their app user will be using, there are thousands of them. So once the app user tries to get to their data (which they already can access via the health provider’s portal if they have a username and password), they will find out that the app is not registered. Bummer, bad app…….. If they are really motivated, they then have to go back to the app provider and identify the health system they are using. Then the app provider needs to contact the health provider and arrange for app registration. Then the app provider has to go back to the patient to tell them to try again. Seriously, in this day and age, when we claim to be patient centric, this will not work.

Allowing health care providers to triage every app only creates a false sense of control and safety, while creating road blocks for patients to use apps. Is a health care provider really going to “vet" the app vendor or technology to decide on giving access or not? Highly unlikely, as they are not equipped to do that in limited time.  Does it even make a difference which technology is used to access the data? Why? Better to allow blocking of “misbehaving” apps, but allow API usage by default.

The control should be with the patient which app to use to access his/her data, not with the health care provider. This is a fundamental choice that is much more aligned with the intent of the rule.

I think EPIC already uses these concepts with its clients. I register my app once with Epic for production use and their customers let my patients access their data through my app, without those health care providers separately “vetting” my app.

Denis.

--
You received this message because you are subscribed to the Google Groups "Cerner FHIR Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-devel...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.

Michele Mottini

unread,
Mar 22, 2019, 11:36:28 AM3/22/19
to Cerner FHIR Developers

I honestly believe such process won’t work for mass consumer apps. The app provider simply does not know upfront which health system their app user will be using, there are thousands of them. So once the app user tries to get to their data (which they already can access via the health provider’s portal if they have a username and password), they will find out that the app is not registered. Bummer, bad app…….. If they are really motivated, they then have to go back to the app provider and identify the health system they are using.

In the rule app developers are classified as 'API Users' as well, so they can preemptively ask their app(s) to be enabled

  - Michele
  CareEvolution Inc

L.H.D. Mulder

unread,
Mar 22, 2019, 11:39:29 AM3/22/19
to 'Denis Mulder' via Cerner FHIR Developers
Yes, I agree, but that is not feasible with thousands of health care providers out there. You would have to do it with every health care provider as you will not know which one your potential app user out there will be using. Somewhat doable for large companies like Apple, not for the average start-up or even mid-size app provider.

--
You received this message because you are subscribed to the Google Groups "Cerner FHIR Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-devel...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.

Jay G

unread,
Aug 14, 2019, 12:41:15 PM8/14/19
to Cerner FHIR Developers
Agreed that app's should be whitelisted or blocked in the OAuth management portal at the app level and not at the clinic level. It's just a giant waste of time for all our teams just for security theater.



On Friday, March 22, 2019 at 10:39:29 AM UTC-5, L.H.D. Mulder wrote:
Yes, I agree, but that is not feasible with thousands of health care providers out there. You would have to do it with every health care provider as you will not know which one your potential app user out there will be using. Somewhat doable for large companies like Apple, not for the average start-up or even mid-size app provider.
On Mar 22, 2019, at 11:36 AM, Michele Mottini <mi...@careevolution.com> wrote:


I honestly believe such process won’t work for mass consumer apps. The app provider simply does not know upfront which health system their app user will be using, there are thousands of them. So once the app user tries to get to their data (which they already can access via the health provider’s portal if they have a username and password), they will find out that the app is not registered. Bummer, bad app…….. If they are really motivated, they then have to go back to the app provider and identify the health system they are using.

In the rule app developers are classified as 'API Users' as well, so they can preemptively ask their app(s) to be enabled

  - Michele
  CareEvolution Inc


--
You received this message because you are subscribed to the Google Groups "Cerner FHIR Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages