Hospitals list for beta testing

503 views
Skip to first unread message

Dan Bayley

unread,
Dec 11, 2017, 6:34:48 AM12/11/17
to Cerner FHIR Developers
Hello

We are in the process of looking at the sandbox to integrate with the Millennium FHIR APIs under MU3.

I would like to identify hospitals/areas ready for beta testing purposes and to start to recruit users ahead of release.

I note from other similar threads that you do not publish hospital lists publicly.

Please can you put me in touch with the relevant team so we can have a discussion about preparing for beta testing activities.


Thanks

Dan

Dan Bayley

unread,
Jan 3, 2018, 7:22:01 AM1/3/18
to Cerner FHIR Developers
Is anyone able to provide any clarity on this?
I am particular interested in hospitals in the NY area.
Thanks

Mark Gidman

unread,
Jan 8, 2018, 1:07:13 PM1/8/18
to Cerner FHIR Developers
Hi Dan,

As you've noted, Cerner doesn't provide this information however you can find a lot of it online.  Try this link: https://www.cerner.com/about/awards

In terms of beta testing, your best bet is to find a local Cerner health system and start building relationships if you don't have any already.  From what we can tell, most of the Cerner world either already has FHIR or is on a path to get there soon. However, a lot of the work involved in selling a provider facing FHIR app right now is still traditional enterprise relationship building. You've got to get out and meet people. Try looking for a regional Cerner user group or going to HIMSS. Later in the year you can go to CHC, which provides a wealth of customer contact - easily your best bet in the Cerner world.

Cerner does a pretty good job of exposing validated apps to their customers but it's still a new way to buy software in the marketplace. Health systems are coming up to speed on it, but it's a big change and will take some time.

Good luck!
- Mark

Adrian Gropper

unread,
Jan 13, 2018, 10:26:25 PM1/13/18
to Cerner FHIR Developers
Hi Mark,



--
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.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/8158710f-8541-4729-9f1b-b6d55625f1ed%40googlegroups.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.

Adrian Gropper

unread,
Jan 13, 2018, 10:45:45 PM1/13/18
to Cerner FHIR Developers
Hi Mark,

It's difficult to provide a good user experience for patients when their ability to use their portal username and password may or may not work with the FHIR API. Open.Epic makes the list of accessible providers easily visible at https://open.epic.com/MyApps/Endpoints This is very useful to patients and developers alike.

Why would the list of accessible hospitals be proprietary? If it is proprietary, what would be the rules to access? How many Cerner hospitals currently allow patient-directed access to their FHIR API?

Thank you,

Adrian

On Mon, Jan 8, 2018 at 1:07 PM, Mark Gidman <ma...@juxly.com> wrote:

--
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.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/8158710f-8541-4729-9f1b-b6d55625f1ed%40googlegroups.com.

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

Mark Gidman

unread,
Jan 15, 2018, 3:12:14 AM1/15/18
to Cerner FHIR Developers
Hi Adrian,

I understand your perspective but I don't have the answers. I am just a vendor like yourself.

I do know that Cerner provides a single FHIR API instance that is shared by all Cerner customers. In order for a health system to use that instance they have to configure their Millennium instance to connect to it. I believe there is some financial component that comes into play between the health system and Cerner but I do not know the details of it.  Individual health systems are not required to use Cerner's API to deliver the required MU3 patient facing API - they can do it however they want to. This may be part of the reason behind the lack of a list. I do not know.

Good luck with your app.

- Mark



On Saturday, January 13, 2018 at 9:45:45 PM UTC-6, Adrian Gropper wrote:
Hi Mark,

It's difficult to provide a good user experience for patients when their ability to use their portal username and password may or may not work with the FHIR API. Open.Epic makes the list of accessible providers easily visible at https://open.epic.com/MyApps/Endpoints This is very useful to patients and developers alike.

Why would the list of accessible hospitals be proprietary? If it is proprietary, what would be the rules to access? How many Cerner hospitals currently allow patient-directed access to their FHIR API?

Thank you,

Adrian
On Mon, Jan 8, 2018 at 1:07 PM, Mark Gidman <ma...@juxly.com> wrote:
Hi Dan,

As you've noted, Cerner doesn't provide this information however you can find a lot of it online.  Try this link: https://www.cerner.com/about/awards

In terms of beta testing, your best bet is to find a local Cerner health system and start building relationships if you don't have any already.  From what we can tell, most of the Cerner world either already has FHIR or is on a path to get there soon. However, a lot of the work involved in selling a provider facing FHIR app right now is still traditional enterprise relationship building. You've got to get out and meet people. Try looking for a regional Cerner user group or going to HIMSS. Later in the year you can go to CHC, which provides a wealth of customer contact - easily your best bet in the Cerner world.

Cerner does a pretty good job of exposing validated apps to their customers but it's still a new way to buy software in the marketplace. Health systems are coming up to speed on it, but it's a big change and will take some time.

Good luck!
- Mark

On Wednesday, January 3, 2018 at 6:22:01 AM UTC-6, Dan Bayley wrote:
Is anyone able to provide any clarity on this?
I am particular interested in hospitals in the NY area.
Thanks

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.

Andrew Torres

unread,
Jan 15, 2018, 10:12:15 AM1/15/18
to Cerner FHIR Developers
Adrian,

The list of live clients is something that is not publicly available, and currently do not have plans to make public with regards to provider APIs. We do have intentions on making the list of patient facing APIs public, but are coordinating with our clients currently. The endpoint information does not belong to Cerner, and clients, in these security conscious times, need to be made aware of the information being public, provide meaningful feedback, and adjust to the culture changes. Cerner ultimately agrees with the overall principal of making the information available, but we are not the covered entity that it responsible for the data.

Mark also brings up other valid points. Not all of our clients are using out APIs, not all are using our portal, and they may never have any intention of using our technologies in this space. This is why working with clients directly is the quickest path to the information needed in connecting with the APIs. Clients may chose publish the information themselves.

Thanks,
Drew Torres


On Saturday, January 13, 2018 at 9:45:45 PM UTC-6, Adrian Gropper wrote:
Hi Mark,

It's difficult to provide a good user experience for patients when their ability to use their portal username and password may or may not work with the FHIR API. Open.Epic makes the list of accessible providers easily visible at https://open.epic.com/MyApps/Endpoints This is very useful to patients and developers alike.

Why would the list of accessible hospitals be proprietary? If it is proprietary, what would be the rules to access? How many Cerner hospitals currently allow patient-directed access to their FHIR API?

Thank you,

Adrian
On Mon, Jan 8, 2018 at 1:07 PM, Mark Gidman <ma...@juxly.com> wrote:
Hi Dan,

As you've noted, Cerner doesn't provide this information however you can find a lot of it online.  Try this link: https://www.cerner.com/about/awards

In terms of beta testing, your best bet is to find a local Cerner health system and start building relationships if you don't have any already.  From what we can tell, most of the Cerner world either already has FHIR or is on a path to get there soon. However, a lot of the work involved in selling a provider facing FHIR app right now is still traditional enterprise relationship building. You've got to get out and meet people. Try looking for a regional Cerner user group or going to HIMSS. Later in the year you can go to CHC, which provides a wealth of customer contact - easily your best bet in the Cerner world.

Cerner does a pretty good job of exposing validated apps to their customers but it's still a new way to buy software in the marketplace. Health systems are coming up to speed on it, but it's a big change and will take some time.

Good luck!
- Mark

On Wednesday, January 3, 2018 at 6:22:01 AM UTC-6, Dan Bayley wrote:
Is anyone able to provide any clarity on this?
I am particular interested in hospitals in the NY area.
Thanks

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.

Dan Bayley

unread,
Jan 15, 2018, 10:24:01 AM1/15/18
to Cerner FHIR Developers
Hey Mark,

Thanks for your comments.
I think you are referring to the B2B API rather than B2C?

I am interested in the facilities which enable patients to access their data as required under MU3.

As Adrian points out other suppliers publish this list and patients can access their data and use it.

Dan

Adrian Gropper

unread,
Jan 15, 2018, 1:39:16 PM1/15/18
to Cerner FHIR Developers
Hi Andrew,

I would like to understand Cerner's distinction between provider and patient-facing APIs in terms of applicable law including HIPAA and 21stC Cures. A patient-directed access to the FHIR API could be by a licensed practitioner or the patient herself. Is Cerner controlling app registration or the credentials of the person registering the particular instance of the app as a Client?

Regardless of who is responsible for deciding whether an API is is public, Cerner, like Epic, can help by publishing the list of APIs that are live and accessible. That will encourage the various covered entities to announce their policy relative to MU3 and Cures.

What I'm asking for is clarity about is Cerner's policies relative to app vs. client registration including a Cerner-supported public listing of live Cerner endpoints (if the covered entity agrees to public listing). I'm not asking for Cerner to take any responsibility for covered entity decisions or APIs that are not supported by Cerner.

Adrian

To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsubscri...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/f7173f62-e664-45c7-a155-1fc787634f5e%40googlegroups.com.

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

Andrew Torres

unread,
Jan 15, 2018, 3:13:16 PM1/15/18
to Cerner FHIR Developers
Adrian,

Patient directed exchange must be handled with patient credentials against our patient endpoint. There is no defined/accepted process to have a provider from an external system authenticate our authorization server to act on behalf of a patient. Consumer directed exchange in our implementation is limited to patient retrieving their own data through an application of their closing.Cerner controls the app registration process. Clients are responsible for issuing credentials that enable user access to APIs.

Unfortunately we have contractual obligations to protect our clients and do not feel it is appropriate to publish the endpoints at this time. Once clients have the opportunity to provide feedback we plan on publishing clients that do not object.

Cerner is fully supportive of publishing the APIs, but will wait for client feedback.

Thanks,
Drew
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsub...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.

To post to this group, send email to cerner-fhir...@googlegroups.com.

Adrian Gropper

unread,
Jan 15, 2018, 3:53:26 PM1/15/18
to Cerner FHIR Developers
Thanks Andrew for engaging in this conversation about who controls what.

Starting with the access authorization model that is already supported by Cerner and Epic is a good thing because it allows all of us to learn together on how to serve "providers from an external system".

Your statement: "Cerner controls the app registration process. Clients are responsible for issuing credentials that enable user access to APIs." seems to be saying that a patient can register a Client with Cerner and then issue credentials to whomever they choose. This is how our HIE of One reference implementation project currently works with Open.Epic and CMS BlueButton on FHIR. The patient registers their instance of the app as a client with Epic or CMS and then the patient can control access by providers from an external system.

The client registration process is currently an awful user experience because OAuth Dynamic Client Registration and Refresh Tokens are not implemented by either Epic or CMS but our HIE of One project has demonstrated that it works. It's notable that the recent ONC announcement of the draft Trusted Exchange Framework and Common Agreement (TEFCA) calls for Dynamic Client Registration and Refresh Tokens.

Until then, the best we can do is to help the patient manually register their client instance with Cerner as we do with Epic, wait for a live endpoint (is there one today?) and repeat the patient authentication whenever they want to delegate temporary access to an external provider for some number of minutes. HIE of One would like to add at least one live Cerner endpoint to our demonstration. Can we do that?

Adrian


Thanks,
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsubscri...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/617e216d-f416-4b64-b6a6-a226e5004e24%40googlegroups.com.

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

Andrew Torres (Cerner)

unread,
Jan 15, 2018, 4:22:28 PM1/15/18
to Cerner FHIR Developers
Yes and no to that first point. A patient can register for 1 client ID, but that client id is not automatically whitelisted everywhere. The client ID will need to be whitelisted at the request of our clients.

There are a number of live clients. Do you have additional information/material on the application? We may be able to reach out to a live client to learn more about it. 

-Drew

Thanks,
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsub...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.

Adrian Gropper

unread,
Jan 15, 2018, 5:06:22 PM1/15/18
to Cerner FHIR Developers
Our application is described at http://hieofone.org/ The source code links are on the website along with a 2-minute video, a white paper, a poster, and links to the key standards we demonstrate. The video has not been updated since we added CMS BlueButton on FHIR but the github is current.

There are currently 83 provider systems that are listed on Open.Epic and we've been able to access live data from all of the ones we have tried so far. Our ability to test is limited by the fact that we need real patients with real patient portal credentials to do the live test.

Whitelists are also addressed in the draft TEFCA proposal but from a different perspective that I think you are using the term. The ability for a Covered Entity to block a client to their API was extensively discussed by the API Task Force and is now a matter of record. Briefly put, the circumstances under which a CE can block a patient-directed app are very limited. If the CE wants to run a whitelist or blacklist, they can ojnly use it to warn the patient but the patient can click-through the warning and gain access anyway.  Beyond that, the CE would need to show that the app is mis-behaving in some way that endangers other patients, such as a denial of service attack, in order to block patient-specified access to the API.

I see how hard Cerner and Epic are working to make useful APIs and support the developer community and I deeply appreciate it. The point of my request is to make as many of the policies that affect patient-directed access as public as possible. Patients and physicians are harmed by the lack of transparency in our health care systems. Have you tried to get an estimate of out-of-pocket expenses or to see who has accessed your prescription records via Surescripts? Have you tried to figure out whether your colonoscopy will be considered screening or diagnostic? (The difference to your pocketbook could be $1-2,000).

I'm not trying to lay responsibility for all policy transparency at Cerner's feet but I am asking for Cerner to make their policies on API access as clear and public as possible. The publishing of client registration and API endpoints, the criteria for issue of 1 client ID, the tracking of how long it takes for a client ID to be whitelisted by each particular CE, the availability of Refresh Tokens regardless of how long each CE decides to set them, the listing of how long a CE has set their default and maximum Refresh Token lifetime, etc... are not trade secrets. It's just a matter of how transparent Cerner wants to be about the user experience of patients and developers.

Adrian


Thanks,
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsubscri...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.

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

Andrew Torres (Cerner)

unread,
Jan 15, 2018, 5:15:53 PM1/15/18
to Cerner FHIR Developers
Our terms of use can be found on our site [1], authorization flows are described in technical documentation [2]. These 2 documents cover our policies and any technical question you have about the APIs. 


Thanks,
Drew

Thanks,
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsub...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.

Adrian Gropper

unread,
Jan 15, 2018, 5:47:17 PM1/15/18
to Cerner FHIR Developers
With respect to the Terms of Use [1] https://code.cerner.com/en/terms-of-use
  • What parts of the FHIR API or any of the process are Cerner proprietary? Are you just saying that the documentation is copyright or is there something else?
  • Under what circumstances would a person registering for a client ID be charged a fee?
  • 3.2.C - Does this just mean that the app will conform to whatever terms of use a CE decides to post on their portal or is it more than that?
  • What is 3.4 about. Our app is licensed under GPLv3. Does this violate your terms of use?

Adrian



Thanks,
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsubscri...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/19e99c92-571d-4c57-9c3b-753de0faacac%40googlegroups.com.

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

Andrew Torres (Cerner)

unread,
Jan 15, 2018, 6:06:47 PM1/15/18
to Cerner FHIR Developers
1.) Relationships, contracting, terms, and how the API interacts with Cerner are all considered proprietary.
2.) When the request is not a direct to consumer app covered by regulation.
3.) Yes, and any technologies that you may be dependent on are properly licensed.
4.) No if your app is open source that is fine. Just talks about require users to make changes that may muck up open source licenses.

-Drew

Thanks,
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsub...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.

Adrian Gropper

unread,
Jan 15, 2018, 6:29:24 PM1/15/18
to Cerner FHIR Developers
1. If we (HIE of One) decides to publish specific instructions and screen shots on how a patient can register their HIE of One instance with Cerner (instead of pointing the patient to  [2] http://fhir.cerner.com/authorization/ ), would we be violating anything?

2. Is any app that is registered by a consumer free to register? If the app Client ID is tied to the Cerner patient ID of the registrant so that app can only be used for access to the API scope for that specific patient then is that app, by definition, free of registration fees?

3. Open.Epic sites post their terms of use right after the patient authenticates and before they issue an authorization. Is this click-through by the patient all that is needed by Cerner? The patient that gets an Epic ClientID does not know at that time which of the 83 CEs they may want to access. That determination is made later when they pick from a list, authenticate, and seek authorization. As far as the client app being adequately regulated and licensed, that's clear.

4. I still don't understand 3.4. Can you give an example of how an API (FHIR, SMART, or proprietary) could muck up anything related to any software licenses?

Adrian


Thanks,
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsubscri...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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+unsubscri...@googlegroups.com.

To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/6abcb82d-0c6a-4967-b1e1-b029f84d2654%40googlegroups.com.

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

Andrew Torres (Cerner)

unread,
Jan 15, 2018, 6:46:23 PM1/15/18
to Cerner FHIR Developers
1.) No objections.
2.) Yes, but the client ID is tied to a client environment because technically they are designed to be assigned per app not per consumer. This seems to more of a semantic thing with the way you are implementing your framework. If a consumer developed their own app and wanted to use that app at multiple sites, it will just need to be on boarded to each client.
3.) No, this terms of use acceptance is done when creating an account at this time. When a user is authorizing an app they have already connected the app to the API and already accepted the terms.
4.) I don't think I have a practical example at this time. The idea of having open source code as part of the app and then requiring someone to modify the code in a certain way that may violate open source licenses is what is trying to be prevented by the language.

-Drew

Thanks,
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-developers+unsub...@googlegroups.com.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.



--

Adrian Gropper MD

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

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.

kevin maloy

unread,
Jan 15, 2018, 7:04:36 PM1/15/18
to cerner-fhir...@googlegroups.com
hey. 

im a patient at an epic shop. 

love blockchain. 

i’d like to try hie of one. 

how do i download?  searched ios app store. 

kevin. 




Thanks,
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.



--

Adrian Gropper MD

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

--
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.



--

Adrian Gropper MD

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

--
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.



--

Adrian Gropper MD

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

--
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.



--

Adrian Gropper MD

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

--
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.



--

Adrian Gropper MD

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

--
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.



--

Adrian Gropper MD

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

--
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.
--
mobile.

Adrian Gropper

unread,
Jan 15, 2018, 7:56:24 PM1/15/18
to cerner-fhir...@googlegroups.com
I replied privately. This is a Cerner list. - Adrian


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

Mark Gidman

unread,
Jan 16, 2018, 12:18:10 PM1/16/18
to Cerner FHIR Developers
It's the same API. There is no other one.

MU3 requires hospitals/providers to provide access to the data to patients. Individual hospital systems can choose to meet that requirement using whatever software they want. Just because they have Cerner as their EMR doesn't mean they have to use Cerner to deliver the patient facing API. It's up to the hospital to decide and there are a myriad of other mechanisms available to health systems to meet this requirement.

For whatever reason, Cerner has chosen at this point not to release the list of who of their customer's that are and aren't using the Ignite API to meet the requirement. Who knows, they may change their mind as the deadline approaches. 

As far as registering, developing, building and deploying a patient facing app - all that is available to anyone via the self help portal. Cerner does nothing to block it and has spent quite a lot of energy promoting it. I've personally been at almost half a dozen events where the Cerner team was working hard to promote awareness and usage of the patient facing API's. 

Adrian Gropper

unread,
Jan 26, 2018, 10:06:03 AM1/26/18
to Cerner FHIR Developers, SMART on FHIR
"Apple has worked with three vendors of electronic medical records for the first wave of its apps: Epic, Cerner and AthenaHealth. More hospitals and other electronic health vendors will be able to join in coming months."

Does anyone have details of the standards and policies that are being deployed? How is this user experience going to be accessible to other developers?

Adrian




On Tue, Jan 23, 2018 at 10:10 AM, Adrian Gropper <agro...@healthurl.com> wrote:
Hi Drew,

Unfortunately, it's still not clear how the developer of a patient-directed app is supposed to test and support patient-directed access to the Cerner API.

I understand that providers have a say in whether they expose a patient-directed endpoint or not. I do not understand why, once a provider decides to expose a patient-directed endpoint, Cerner does not publish that and take responsibility for its operation.

Absent a published list of patient-directed endpoints how would a developer deploy and test a client app? Patients have to start with the name of a provider as the first step. Where does the patient-user that has patient portal credentials go to click on the endpoint? That patient authentication is in the context of our app so our app has to discover it somehow. Is Cerner suggesting that each app developer is responsible for discovering these endpoints provider-by-provider and coding each one separately? Is Cerner suggesting that some business will maintain a Provider Endpoint Directory that developers would subscribe to?

Finally, I'm still not clear if there is a live provider endpoint that we can test against?

Thank you,

Adrian
Adrian Gropper MD

Adrian Gropper

unread,
Jan 26, 2018, 10:06:08 AM1/26/18
to Cerner FHIR Developers
Hi Drew,

Unfortunately, it's still not clear how the developer of a patient-directed app is supposed to test and support patient-directed access to the Cerner API.

I understand that providers have a say in whether they expose a patient-directed endpoint or not. I do not understand why, once a provider decides to expose a patient-directed endpoint, Cerner does not publish that and take responsibility for its operation.

Absent a published list of patient-directed endpoints how would a developer deploy and test a client app? Patients have to start with the name of a provider as the first step. Where does the patient-user that has patient portal credentials go to click on the endpoint? That patient authentication is in the context of our app so our app has to discover it somehow. Is Cerner suggesting that each app developer is responsible for discovering these endpoints provider-by-provider and coding each one separately? Is Cerner suggesting that some business will maintain a Provider Endpoint Directory that developers would subscribe to?

Finally, I'm still not clear if there is a live provider endpoint that we can test against?

Thank you,

Adrian
Adrian Gropper MD

Andrew Torres (Cerner)

unread,
Jan 26, 2018, 10:19:06 AM1/26/18
to Cerner FHIR Developers
You can test your application against our sandbox. Because a client decided to expose their endpoint doesn't equate to meaning they want it published.

Once a patient has their portal credentials. Most clients, once live with the API, will provide instructions to the patient on how to request applications be connected to the facility. At that point, a health care organization can request the app be connected with with Cerner, and the developer can then begin to work to on-board their application to the client.

There is no published live endpoint with a client that you can test with. If you have a client that is interested in piloting your application, then you will be given information on how to access their endpoint. In the absence of that you can test in our sandbox.

-Drew

Jenni Syed (Cerner)

unread,
Jan 26, 2018, 10:29:05 AM1/26/18
to Cerner FHIR Developers
Hi Adrian,

I'll echo Drew's comment about testing in our sandbox. That's where we intend most of the testing to take place, though clients may also run some basic tests when enable your application (it will vary by client). Take a look at the test patients and data we have set up here. If there's data your application may need that is missing (and should be accessible from the functionality our implementation of FHIR has exposed), let us know by posting a separate thread. 

Regards,
~ Jenni

Adrian Gropper

unread,
Jan 26, 2018, 1:25:32 PM1/26/18
to Cerner FHIR Developers
Drew and Jenni,

This thread is about the patient as user experience with respect to authorization on a live API. These questions cannot be answered with the sandbox. Lack of uniformity and lack of predictability in the user experience across different providers is a major problem for patients as users.

To answer Drew's question about what I mean by policies, let's use Refresh Tokens an example of a policy that needs to be published by Cerner and Epic, etc.... Absent refresh tokens, a patient has to sign-in each time they want to access a provider's API. Let's take Cerner Healthe Clinic – Kansas City, Missouri as an example API. It's accessible via the Apple iPhone operating system using a Refresh Token. It's likely to be accessible via Sync4Science using a Refresh Token. Is it accessible to an app that a patient registers using a Refresh Token? If not, where is the policy that determines the distinction between iPhone, S4S, and a patient-directed app?

The policy associated with Refresh Tokens may be set by Cerner as API operator or by Cerner Healthe Clinic as provider. That's potentially confusing to patients but maybe unavoidable. Either way, as an app developer, lack of uniformity of user experience is very frustrating and not likely to to meet the "without special effort" requirement in 21st C Cures. Lack of public access to policies such as refresh tokens and API endpoints magnifies this problem.

The sandbox can't address this issue. Having a well-known Santa Claus account with fake data and credentials in each Cerner provider's system would go a long way to make this issue tractable because any app user could test authorization behavior in the same way. Is there a policy reason why Cerner or Cerner providers don't have a Santa Claus account?

How can we make this better for our patients?

Adrian




--
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+unsubscri...@googlegroups.com.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/268b7978-dbef-43d1-87c3-51a187a601c9%40googlegroups.com.

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

Adrian Gropper

unread,
Mar 19, 2018, 8:30:36 PM3/19/18
to Cerner FHIR Developers
Cerner,

I'd like to remind all of us that developers need clear policies and open documentation. Please see the note below that was sent directly to me. This is not the first time a developer group has approached me privately because they are self-censoring their comments to the open list. (I got permission to repost this one, minus the signature.)

"Hi Adrian, Just wanted to thank you for this thread on Cerner's forum: https://groups.google.com/d/msg/cerner-fhir-developers/C9nanhzFee8/anM_s3LtAwAJ I've been looking into how to integrate a patient-facing app with a Cerner health system and have been disappointed by the Cerner docs and lack of endpoint list like Epic. Your questions and points on there were super useful in getting me up to speed on the lackluster developer experience, and I can't wait for TEFCA or new requirements for a better experience with refresh tokens (Epic also wants me to pay for a refresh token). Thanks for fighting the good fight, "

Can you address the policy on issuing refresh tokens for patient-directed apps?
Do you recognize that the lack of a public endpoints list is a severe hardship to developers and end-users?

Thank you!

Adrian





On Friday, January 26, 2018 at 1:25:32 PM UTC-5, Adrian Gropper wrote:
Drew and Jenni,

This thread is about the patient as user experience with respect to authorization on a live API. These questions cannot be answered with the sandbox. Lack of uniformity and lack of predictability in the user experience across different providers is a major problem for patients as users.

To answer Drew's question about what I mean by policies, let's use Refresh Tokens an example of a policy that needs to be published by Cerner and Epic, etc.... Absent refresh tokens, a patient has to sign-in each time they want to access a provider's API. Let's take Cerner Healthe Clinic – Kansas City, Missouri as an example API. It's accessible via the Apple iPhone operating system using a Refresh Token. It's likely to be accessible via Sync4Science using a Refresh Token. Is it accessible to an app that a patient registers using a Refresh Token? If not, where is the policy that determines the distinction between iPhone, S4S, and a patient-directed app?

The policy associated with Refresh Tokens may be set by Cerner as API operator or by Cerner Healthe Clinic as provider. That's potentially confusing to patients but maybe unavoidable. Either way, as an app developer, lack of uniformity of user experience is very frustrating and not likely to to meet the "without special effort" requirement in 21st C Cures. Lack of public access to policies such as refresh tokens and API endpoints magnifies this problem.

The sandbox can't address this issue. Having a well-known Santa Claus account with fake data and credentials in each Cerner provider's system would go a long way to make this issue tractable because any app user could test authorization behavior in the same way. Is there a policy reason why Cerner or Cerner providers don't have a Santa Claus account?

How can we make this better for our patients?

Adrian



On Fri, Jan 26, 2018 at 10:29 AM, Jenni Syed (Cerner) <jenni...@cerner.com> wrote:
Hi Adrian,

I'll echo Drew's comment about testing in our sandbox. That's where we intend most of the testing to take place, though clients may also run some basic tests when enable your application (it will vary by client). Take a look at the test patients and data we have set up here. If there's data your application may need that is missing (and should be accessible from the functionality our implementation of FHIR has exposed), let us know by posting a separate thread. 

Regards,
~ Jenni

--
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.
To post to this group, send email to cerner-fhir...@googlegroups.com.

Jenni Syed (Cerner)

unread,
Mar 20, 2018, 11:59:24 AM3/20/18
to Cerner FHIR Developers
Hi Adrian,

As previously stated, we will be publishing the endpoints for patient access. We're working through the approval process for this now.

For apps that are consumer facing (the consumer is the purchaser/downloader and user), there is no charge to use the refresh token workflow (also known as the offline_access scope).

~ Jenni

Adrian Gropper

unread,
Mar 20, 2018, 12:23:51 PM3/20/18
to cerner-fhir...@googlegroups.com
Great to hear. 

With respect to refresh tokens, aside from cost, who will control the policy for issuance and what will that policy be? For example, if Apple gets to use a refresh token for Hospital x will any patient-directed access get the same privileges or will there be some “certification” entity involved?

Thank you,

Adrian

--
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.

Jenni Syed (Cerner)

unread,
Mar 20, 2018, 1:45:58 PM3/20/18
to Cerner FHIR Developers
We do not certify patient access applications, we only require that for provider or system based access applications. 

Any patient facing application can use the offline_access scope, it doesn't require the presence of any other application (it only requires that the site has set up the MU 3 access APIs/Ignite at their site). 

Some considerations/recommendations:

  • The application should describe to the user how they'll be using the patient data (eg: the application's own terms of service). This is true regardless of using offline or online access. 
    • Our authorization page will describe the resources they have access to, and for how long. However, we can't describe how/what you use the data for.
  • We also provide the SMART "manage" endpoint in our conformance - the user can use this to de-authorize previously authorized applications. You should consider linking to this endpoint within your application if using offline_access (they can also access this from their portal).

The basic process as of right now is:
  • The patient-facing app registers in our sandbox and tests.
  • Once the app is ready for production:
    • If the *Patient* is the requestor:
      • The patient is given information by the provider about where the apis are hosted and how to access them.
    • If the *Provider* is the requestor:
      • The provider logs an eService issue to us to request the application be whitelisted in whatever environments they need.
      • There is documentation on our Ignite reference pages that they have access to regarding this process.
    • If the *Application owner* is the requestor:
      • You can post here or reach out to the admins of this group to request your app is moved to production. If you have a specific provider you're working with, let us know who that is and we'll trigger the whitelist process.
    • Currently, each new system requires a request to whitelist your application with that system
We want to make this process more self-service in the future and as the APIs roll out more broadly for patient access.

We also need to get this documentation moved to our FAQs/process on our code site.

~ Jenni

Michele Mottini

unread,
Mar 20, 2018, 4:02:16 PM3/20/18
to Cerner FHIR Developers
    • If the *Application owner* is the requestor:
      • You can post here or reach out to the admins of this group to request your app is moved to production. If you have a specific provider you're working with, let us know who that is and we'll trigger the whitelist process.


Could you please move our myFHR app to production? It will keep the same client IDs, correct?

We do not have any specific provider we are working with - so I guess we are stuck until we found one, correct?

  Thanks

  - Michele
  CareEvolution Inc

Adrian Gropper

unread,
Mar 20, 2018, 5:18:39 PM3/20/18
to Cerner FHIR Developers
Thank you Cerner for planning to move the settled elements of this thread to a public FAQ along with the various endpoints. I hope you announce those updates to this thread as that happens. It would be news if we're seeing a competition between Cerner and Epic as to how patient-centered and transparent they are with respect to information sharing and how simple the user experience will be.

I'm having some trouble mapping the patient experience into the terms you use. Please allow me to describe the current patient experience with paper Release of Information (ROI) forms and ask you to map into the terminology you use in these policies and documentation. I'm imagining the digital user experience to be:
  1. The paper ROI form is replaced by a form in the patient portal (the patient has already been authenticated and can see whatever information is available for sharing if they want to look)
  2. The ROI form allows the patient to specify a FHIR endpoint as the TO: or Destination: address. This FHIR endpoint may be a Client App or a Requesting Party that operates a Client App. (the paper ROI form does not distinguish between the institution or the person that may or may not be an institution and fulfills the request either way so the patient doesn't have to worry.)
  3. The patient signs the ROI form and presents it to the records department. The records department should check their driver's license to ensure they are the subject of the FHIR resource being shared. (in the digital version of the patient experience, the fact that the form is presented in the same context (step 2.) as the ability to view means that the verification of the patient's authority has already happened when they got their UserID and Password to the portal.)

The patient has just hit Send or OK or Signed or whatever on their digital ROI form and might be tempted to close the browser and say "Gee that was easy!" They will never have to visit the basement records room again. They will write their local politician and they will donate extra money to the hospital.

We all know that there are some "details" on the path to this user experience.

  • One detail is the ability of the portal operator (the hospital) to warn the patient that the destination they have entered is not "certified" or "whitelisted" or whatever we choose to call it and ask the patient "Are you sure?" This right to ask the patient "Are you sure?" was debated extensively and documented by the API Task Force. There seems to be consensus that asking this kind of question is not a burden on the patient experience and would not be considered information blocking.
  • A number of other "details" relate to the user experience when the Client App or Requesting Party comes to the FHIR endpoint and asks for an access token. Please document how and when this would be presented to the patient:
    • Is the Client App dynamically registered as soon as the patient clicks Send or at some other time?
    • Can the Client App request Refresh Tokens as part of the patient experience?
    • Does the patient need to do anything else before they close the portal and smile on how easy that was?

I recognize that other folks may have different ideas about what "without special effort" could mean in the 21st Century Cures Act so if my presentation of the patient experience is misguided, please propose another example of "without special effort" consistent with HIPAA and the API Task Force recommendations.

For now, if we can use this description of the patient experience, can Cerner map the various terms (patient-facing app, registers, moved to production, etc...) into this example?

Thanks!

Adrian










--
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.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/CAMK4NFOwb3Uy7WApRifuQ6gSBjzeyo8-Xw7RgqEbiPpu4VRBdw%40mail.gmail.com.

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

Jenni Syed (Cerner)

unread,
Mar 22, 2018, 2:54:16 PM3/22/18
to Cerner FHIR Developers
Adrian,

All of the process I described above is out-of-band and currently done once per app per provider system. Once the provider whiltelists an app, it's available for all patients that have data at that system. The patient's experience for this, if they're the one that is having to do the initial request to use the application with that provider, is that they call or ask their provider to allow the app. 

An example: You as a patient want to user Apple Health (once non-beta) at a provider that isn't currently listed in that app. You could call your provider and ask if you can or when you can use that app. They would either say you already can (and then clarify how you find them...) or they would reach out to us and we would start the process to get Apple Health whitelisted. (Disclaimer: I don't know what process Apple will actually use once out of beta - I'm just using this application as an example since the Apple Health app was brought up earlier.)

Note, an additional step that you as an app developer could take: Any application could *also* choose to have a way for their users to request new providers be added if the application isn't aware of them today.

The patient approving the app to access *their* data is done exactly as you see when you run your app in our sandbox: If using offline access, the patient authorizes it once and the app can continue getting tokens via the refresh token for as long as the patient decides to keep the authorization. The patient can remove the authorization via the "manage" endpoint as described by SMART (and we recommend apps link to this from their app). This aspect, I believe, is already well documented and is something developers experience live within our sandbox. If you feel there are documentation gaps around this aspect, please let us know what you believe is missing.

If using online access, the patient grants access each time the application is launched/they sign in.

~ Jenni

Adrian Gropper

unread,
Mar 22, 2018, 4:25:42 PM3/22/18
to Cerner FHIR Developers
Hi Jenni,

I'm deeply grateful that Cerner is continuing this conversation in public and thoughtfully providing materials like the "manage" presentation. This response is a bit long because we're touching on five different aspects of the experience we loosely call "interoperability"

(1) Based on your response about "out-of-band" I presume that Cerner is not supporting Dynamic Client Registration. I understand that it's optional in SMART, but I would suggest that this is one of the things that could be considered "special effort" under 21C Cures for patients and maybe even for physicians. I think the policy for Cerner or a Cerner hospital to either support or not Dynamic Client Registration needs to be public and easily accessible. Is Cerner going to give hospitals this option or is it baked in to the software at the Cerner level? These are all critical to meeting the "without special effort" goal.

(2) Patient experience is not the only issue. Lacking Dynamic Client Registration is a huge barrier to innovation and competition. Apple is the most valuable company in the world and they get a huge advantage over a startup or an open source project that then has to invoke a costly manual process as an adoption barrier. This was never an issue with paper ROI forms and fax machines. Does Cerner really want to introduce this costly and discriminatory step into the OAuth process? Given that Cerner's policy is that patient-directed access should be cost-free (I hope I'm interpreting your previous comments accurately) it would seem that Cerner is going to bear the cost of patient-initiated app registration. Can your public policy be explicit about the cost and delay of patient-initiated client registration?

(3) Moving on to offline access and refresh tokens. Does every app, once registered out-of-band or dynamically have the opportunity to offer offline access? If there is any restriction on the access to refresh tokens, can you please publish what that policy is.

(4) Now, separately, to the "manage" endpoint as proposed by Drew in the Cerner presentation. This proposal does represent an option and an improvement over the patient having to sign-in to the patient portal associated with the FHIR endpoint(s) of the institution. It allows the app developer to provide some guidance if the hospital has multiple endpoints or multiple portals. Although I did not see this explicitly in Drew's presentation, I believe the intent is to allow the app developer, e.g.: Apple Health, to provide a single uniform user interface to manage multiple hospitals and their FHIR endpoint. The app could present a single screen with a list of all of the registered endpoints and a Mange link next to each one. This is good. Do all Cerner hospitals support this feature? When Cerner publishes the list of hospital endpoints will it specify which hospitals do not support a manage API?

(5) There is one other possibility for making the patient experience "without special effort" that Drew's presentation does not discuss: Allow the patient to specify the Authorization Server. Slide 8, "Healthcare Is More Complicated" implies that the User is the patient. In the general case, the User in slide 8 could be a physician or other licensed practitioner seeking access for their application. The issuance of an authorization token to the app depends on this provider being credentialed by the authorization server. "without special effort" applies to the physicians as well as the patients. In the ROI form example, the patient is allowed to specify a physician or a family member as the destination for their records. In the paper ROI form case, the hospital does not bear any cost or responsibility to certify that postal address or fax number they received from the patient. This means that effectively, when the destination is specified by a patient, the authorization server has no role in verifying the identity of the destination entity be they a physician or anyone else.

Achieving patient-directed interoperability without special effort can work if the hospital controls both the resource server and the authorization server (as in slide 8) but it means that the hospital is issuing access tokens to *anyone* that comes around with a request that is digitally signed by the patient. I'm not aware of standards that can make this practical. What we do have standards for (OpenID HEART) is for the patient to specify the authorization server and take this responsibility of authenticating a physician or other destination entity away from the hospital. This reduces the hospital's risk and cost. I hope Cerner and SMART will consider joining the HEART workgroup (co-chaired by ONC) and help make this a reality.

Thank you,

Adrian

--
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.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.

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

Michele Mottini

unread,
Mar 22, 2018, 5:48:18 PM3/22/18
to Cerner FHIR Developers
I don't think Dynamic Client Registration is actually a good idea - it removes any possibility of controlling which apps can connect to a provider, and that's too much of a good thing.

I think that the current approach of registering the apps centrally with the EHR vendors is pretty good (as long as it is free and easy - as it is now with Cerner and Epic)

  -Michele
  CareEvolution Inc


Adrian Gropper

unread,
Mar 22, 2018, 5:58:20 PM3/22/18
to Cerner FHIR Developers
Hi Michele,

Your opinion seems to conflict with the API Task Force outcome. Should patients have the right to register an app themselves? How easy should that be?

Adrian

--
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.
To post to this group, send email to cerner-fhir-developers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/CAMK4NFNFYdig8YLcVQUn5iQ7HogzFwRsGjsG64ng7SRu4OJLAQ%40mail.gmail.com.

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

Michele Mottini

unread,
Mar 22, 2018, 6:02:02 PM3/22/18
to Cerner FHIR Developers

 
Should patients have the right to register an app themselves? How easy should that be?

Anyone can register an app on Cerner and it is pretty easy  - but patient in general won't do that, is app developer that would do that

  - Michele
  CareEvolution Inc

Jenni Syed (Cerner)

unread,
Mar 22, 2018, 6:28:33 PM3/22/18
to Cerner FHIR Developers
In line...


(1) Based on your response about "out-of-band" I presume that Cerner is not supporting Dynamic Client Registration. I understand that it's optional in SMART, but I would suggest that this is one of the things that could be considered "special effort" under 21C Cures for patients and maybe even for physicians. I think the policy for Cerner or a Cerner hospital to either support or not Dynamic Client Registration needs to be public and easily accessible. Is Cerner going to give hospitals this option or is it baked in to the software at the Cerner level? These are all critical to meeting the "without special effort" goal.


Our initial MU 3 targeted APIs do not support Dynamic Client Registration. We are watching the TEFCA and other legislation that also calls out this technology, and may require it.

If we want to discuss the merits and risks of the existing legislation, lets move that conversation to a broader thread (and not on our Google Group :) )
 
(2) Patient experience is not the only issue. Lacking Dynamic Client Registration is a huge barrier to innovation and competition. Apple is the most valuable company in the world and they get a huge advantage over a startup or an open source project that then has to invoke a costly manual process as an adoption barrier. This was never an issue with paper ROI forms and fax machines. Does Cerner really want to introduce this costly and discriminatory step into the OAuth process? Given that Cerner's policy is that patient-directed access should be cost-free (I hope I'm interpreting your previous comments accurately) it would seem that Cerner is going to bear the cost of patient-initiated app registration. Can your public policy be explicit about the cost and delay of patient-initiated client registration?


Apple is following the exact process that I outlined above. Providers reach out to us (or Apple reaches out to us) to get providers whitelisted. There is no automated process. I'm not sure how this will change after beta (nothing about our whitelist process will change - they'll be bound by the same process any patient facing application developer is). You can learn more about Apple's healthcare integration at https://www.apple.com/healthcare/

 
(3) Moving on to offline access and refresh tokens. Does every app, once registered out-of-band or dynamically have the opportunity to offer offline access? If there is any restriction on the access to refresh tokens, can you please publish what that policy is.


No restriction for patient access applications, outside of following our documentation on how to authenticate (and not DOS'ing our API :)). As stated in our documentation, this requires confidential client access, which requires a step to register and have access to your app secret (rotation etc). See more info here: http://fhir.cerner.com/authorization/#registration This means that a purely "public" app can't just add offline_access - you have to plan, test/develop for it.
 
(4) Now, separately, to the "manage" endpoint as proposed by Drew in the Cerner presentation. This proposal does represent an option and an improvement over the patient having to sign-in to the patient portal associated with the FHIR endpoint(s) of the institution. It allows the app developer to provide some guidance if the hospital has multiple endpoints or multiple portals. Although I did not see this explicitly in Drew's presentation, I believe the intent is to allow the app developer, e.g.: Apple Health, to provide a single uniform user interface to manage multiple hospitals and their FHIR endpoint. The app could present a single screen with a list of all of the registered endpoints and a Mange link next to each one. This is good. Do all Cerner hospitals support this feature? When Cerner publishes the list of hospital endpoints will it specify which hospitals do not support a manage API?

Yes, a manage link is always present. Without this, a patient cannot properly manage their own privacy/security if an app is unnecessary or unwanted anymore.
 

(5) There is one other possibility for making the patient experience "without special effort" that Drew's presentation does not discuss: Allow the patient to specify the Authorization Server. Slide 8, "Healthcare Is More Complicated" implies that the User is the patient. In the general case, the User in slide 8 could be a physician or other licensed practitioner seeking access for their application. The issuance of an authorization token to the app depends on this provider being credentialed by the authorization server. "without special effort" applies to the physicians as well as the patients. In the ROI form example, the patient is allowed to specify a physician or a family member as the destination for their records. In the paper ROI form case, the hospital does not bear any cost or responsibility to certify that postal address or fax number they received from the patient. This means that effectively, when the destination is specified by a patient, the authorization server has no role in verifying the identity of the destination entity be they a physician or anyone else.

Achieving patient-directed interoperability without special effort can work if the hospital controls both the resource server and the authorization server (as in slide 8) but it means that the hospital is issuing access tokens to *anyone* that comes around with a request that is digitally signed by the patient. I'm not aware of standards that can make this practical. What we do have standards for (OpenID HEART) is for the patient to specify the authorization server and take this responsibility of authenticating a physician or other destination entity away from the hospital. This reduces the hospital's risk and cost. I hope Cerner and SMART will consider joining the HEART workgroup (co-chaired by ONC) and help make this a reality.


We have been watching HEART, and I believe have provided some (at least informal) feedback in the past. We're aware of an upcoming call with the HL7 security group around this, and the "rewrite" proposed for HEART. 

Rainbow Zhang

unread,
Oct 11, 2019, 12:00:55 PM10/11/19
to Cerner FHIR Developers
It's been over a years since Jenni mentioned "Our initial MU 3 targeted APIs do not support Dynamic Client Registration. We are watching the TEFCA and other legislation that also calls out this technology, and may require it.".

I was wondering if that's supported now?

Yegor Hanov (Cerner)

unread,
Oct 11, 2019, 6:32:17 PM10/11/19
to Cerner FHIR Developers
Hello!  We are still waiting for the new regulatory requirements to be released before moving forward with any changes in regards to dynamic registration.

-Yegor (Cerner)
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages