Going From Sandbox to Production questions

[David Breed]

HI All,

I've been creating a sample app (iOS) to test out the capabilities of SMART. Now that I've become more comfortable with working with SMART on FHIR API's, I'm beginning my prep work on creating a production stand-alone app (iOS) for hospitals / doctor's offices and am running into some questions. Hopefully someone can help me out with.

From my understanding, SMART on FHIR is a service that would run on top of another healthcare system, like Epic or Cerner, so each organization would have to have SMART on FHIR implemented in their healthcare system, any chance is there a list of known systems that SMART on FHIR is compatible with? For example, i believe Epic and Cerner support SMART.

Would each organization have to create an app in their SMART account and then I have to manage the client id / FHIR Server Url within my stand alone app? or is there a central SMART server which they just have to authorize / login to?

Those are big questions for now, thanks in advance for any help. 

[Michele Mottini]

Epic, Cerner and Allscripts have working SMART-on-FHIR implementation running on top of their EHRs. They maintain central registry of the app - so you do not have to register at each site - but the FHIR end points are different for each site.

You can register and get more info at https://open.epic.com/, http://fhir.cerner.com/, https://developer.allscripts.com/

  - Michele

  CareEvolution Inc

[Anatoly Postilnik]

Hi all,

Just trying to understand the whole process...

We built an app against an open.epic sandbox. For testing purposes this app just reads patient medication list. Now we would like to implement it against production data. Institutions have published FHIR production server URLs but there is really no info at open.epic how to get the app to work against these production servers. Does this mean that we need to go to the institutions and work with them individually to enable the application? If this is the case - what is the point of publishing production server URLs on open.epic? We thought that the idea of open epic is to get patients (and their providers) access to PHRs from multiple institutions (they still need to authenticate/authorize access for each institution) without the need to deal with individual infrastructures.

Thanks for your input!

Anatoly

[Michele Mottini]

You can register your app at https://open.epic.com/MyApps (log-in with Google), then push the registration to the production sites and then you can use it - using the client ID you got back during the registration process.

   - Michele

  CareEvolution Inc

[Anatoly Postilnik]

Hi Michele,

Thank you for your response. 

Have you actually got your app to work agains production Epic instance with any of the institutions that published  prod URLs on open.epic? I can read the instructions on https://open.epic.com/MyApps and in fact "pushed the registration to the production sites" as you said. 

First, nothing happened (yet). Second, in the sandbox there is a URL of the Auth server, which is not present for any of the production sites. Without it you can't authenticate the user with the institution. 

If you indeed have your FHIR app working with production data - could you please indicate more details how you got there? 

What happened after you "pushed the registration to the sites"?

Did you have to work with the institutions (e.g. get approval from them for your app)?

How is your application accessible (within institution or outside)?

Thank you,

Anatoly

[Michele Mottini]

Have you actually got your app to work agains production Epic instance with any of the institutions that published  prod URLs on open.epic?

Yes. Our app is in the app store - it is called MyFHR. Go to Settings and select Add provider data source to connect to sites

(We also have a Web version: https://myfhr.careevolution.com)

 

Second, in the sandbox there is a URL of the Auth server, which is not present for any of the production sites. Without it you can't authenticate the user with the institution. 

You have the URLs of the FHIR end points, from those you get the FHIR conformance and you extract the authorization (and token) end point URLs from that - as described here

One caveat: Epic is white-listing redirect URLs schemes, so if your app does not use an https:// redirect URLs it might be blocked (we just had this problem with ours)

 

What happened after you "pushed the registration to the sites"?

Nothing visible - after a while the production sites 'know' about your app and you can connect ('a while' not strictly defined - tops 12 hours)

 

Did you have to work with the institutions (e.g. get approval from them for your app)?

No

 

  - Michele

  CareEvolution Inc

 

[Anatoly Postilnik]

MIchele,

Yep, it worked, had to pass /metadata to the FHIR endpoint to get the auth url back. This is different than in the open.epic sandbox where they give you the auth url explicitly (probably would have gotten it there as well had we requested metadata in the sandbox as well - didn't try)

Thank you!

Anatoly

[Adrian Gropper]

After one signs-in to open.epic, you can see the list of 18 hospitals (as of today) that support FHIR access via specified endpoints. This is really helpful and allowed us to test the system for getting real patient data. 

QUESTION 1: Is it ok to re-publish this list of hospitals and endpoints without a login, with credit to Epic as the source, of course?

QUESTION 2: Do Cerner or other vendors publish a similar list and would they allow public reuse, with credit?

Thanks,

Adrian

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhir+unsubscribe@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.

[Adrian Gropper]

In that case, can you make the list on open.epic public so that we can link to it?

Adrian

On Mon, Jun 19, 2017 at 9:56 AM, open.epic - Inquiries <op...@epic.com> wrote:

Hold off on republishing that list. It changes fairly often as more as more organizations turn FHIR on, so the source of truth should be the list on open.epic.

 

Rob Rucker

Epic | Interfaces | 608-271-9000

[Isaac Vetter]

Hi Adrian, All,

This thread is a great read - shoutout to Michelle for always being willing to share his considerate expertise.

The page that you're referencing is available here: https://open.epic.com/MyApps/Endpoints and can definitely be linked to. We've even provided the contents as json to attempt to make it easier on app developers: https://open.epic.com/MyApps/EndpointsJson.

Currently, accessing either of the urls requires that you authenticate with an OpenID provider (such as Google, Yahoo, etc). We tried to make this as easy as possible, while still doing some basic due diligence on gathering contact information for an application developer. This is why we ask developers to login. 

Isaac Vetter

Epic

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@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.

[Adrian Gropper]

Hi Isaac,

Our app is designed to provide a completely consistent user experience as compared to View/Download/Transmit. A patient searches for a provider (just like they do in the MyChart app today but without the limitation to a specific vendor) and is then guided to get an app ID for themselves and then enter their VDT portal credentials via the typical OAuth redirect.

This pattern may be surprising because every time an app is installed on a user's device, a new OAuth client would be registered with Epic. We're doing it this way because our app is designed to aggregate information from any number of different portals, (Epic, Cerner, Allscripts. etc...) and we, as an open source project, do not want liability for being able to see or hold the patient's data.

As I understand it, a design where the patient is acting as their own developer is completely consistent with HIPAA, OCR guidance, and the API Task Force recommendations for patient-directed access. By providing a consistent way to register our app across provider systems, we're also providing a useable solution for longitudinal health records per the 21st C Cures Act.

Placing the list of sites and their endpoints behind a login makes this unified user experience impractical. Because users don't usually know who the EHR vendor is (and some Epic users, such as Partners Healthcare don't use MyChart as their portal), the user would have to register with every possible EHR vendor before they could search for their service provider. 

Adrian

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhir+unsubscribe@googlegroups.com.

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

[Andrew Torres]

How does putting endpoints in front of a login help in that situation? You can register and retrieve the list and update your directory of provider every so often. The cable industry does this today. When a new service provider comes on line, your credentialing system that enables access to content still needs to be on-boarded. I recall when google fiber first rolled out, I didn’t have access to HBOGO until Google was added to the list.

 

Are you expecting consumers to put in their own FHIR URLs? A patient developing their own app still has to meet the technical terms of the APIs publish. It would be helpful to understand what the use-cases are.

[Adrian Gropper]

Hi Drew,

Thanks for engaging here since I'd like to clarify this issue before cross-posting on Cerner and other forums.

Our primary use-case is creating and maintaining a longitudinal health record that is completely controlled by the patient. This is not that different from what Apple is doing with HealthKit and ResearchKit where Apple's privacy policy is "Apple will not see your data." Unlike Apple, we're proposing that the patient's longitudinal health record in the app is accessible as a FHIR service just like the EHRs are accessible as FHIR services.

Each provider has a relationship with the patient and is handing out online access credentials by whatever method they use. These credentials have to be presented, one way or another via the longitudinal health record app. We're trying to make the user experience around connecting the app to a dozen providers (hospitals, physician practices, payers, labs, pharmacies, research studies, wearables, implants, health savings accounts, insurance exchanges) as seamless and consistent as possible.

Each patient has only 3 pieces of information for each service provider: the provider's business name, the patient's ID, and the patient's password. The provider's business name needs to be converted into a link that the app can access as an initial service endpoint. Therefore, somewhere either in the app or on the open internet the app has to find the current list of service endpoints.

If the list of service endpoints is behind a login, the simple question is what is the basis of the restriction? Is it protecting the patient or the service provider? What is a person proving or what are they licensing as part of gaining credentials to access this list?

If there is some logic for putting the list behind an authorization step, then who is in charge of this authorization (keeping in mind that the list might be a combination of hundreds, maybe thousands of vendors and service providers)? Are we assuming that:

(a) every one of these hundreds or thousands of vendors will contribute their endpoints to some registry that all apps can sign-in and use (what is the basis for license that restricts access?), or

(b) every app support organization will poll potentially thousands of vendors and service providers and then make this list available as part of a support contract for their app customers?, or

(c) every vendor and service provider that knows of a FHIR service endpoint makes that information freely accessible. Anyone can decide to maintain the combined list as a public good. 

I can't think of a good analogy where personal data is scattered the way our personal data is scattered in healthcare. My Apple TV does have 50 or so tiles representing services where I might have a login and indeed, I'm stuck waiting for Apple to update that list if I'm to have a chance to connect. Is this the analogy you propose for healthcare? Instead of a list of tiles, Apple would assemble a list of FHIR endpoints that I can search by provider name.

So, in order to make the Apple TV analogy work, Apple would have to license the list from Epic and Cerner and every other vendor and service provider, maybe thousands of these. This treats the list of API endpoints as intellectual property of Epic and Cerner, etc.... I can understand why Epic and Cerner might prefer that but it seems like it could be considered information blocking to license the endpoint associated with a patient-directed access.

Adrian

 

On Mon, Jun 19, 2017 at 6:04 PM, Torres,Drew <Drew....@cerner.com> wrote:

How does putting endpoints in front of a login help in that situation? You can register and retrieve the list and update your directory of provider every so often. The cable industry does this today. When a new service provider comes on line, your credentialing system that enables access to content still needs to be on boarded. I recall when google fiber first rolled out, I didn’t have access to HBOGO until Google was added to the list.

 

Are you expecting consumers to put in their own FHIR URLs? A patient developing their own app still has to meet the technical terms of the APIs publish. It would be helpful to understand what the use-cases are.

 

Thanks,

 

Drew Torres

Strategist

Andrew...@cerner.com | (816) 201-8059

www.cerner.com

 

CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.

[Isaac Vetter]

Hi Adrian, All,

Adrian - I don't necessarily agree with or even understand all of the below, but we did look into making the list of Epic Community member's FHIR endpoints public. These two urls no longer require logging in with an OpenID account:

• https://open.epic.com/MyApps/Endpoints
• https://open.epic.com/MyApps/EndpointsJson

Isaac Vetter

Epic

 

CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.

[Michele Mottini]

These two urls no longer require logging in with an OpenID account:

• https://open.epic.com/MyApps/Endpoints
• https://open.epic.com/MyApps/EndpointsJson

Very nice,  thanks. This will allow our app to grab the latest JSON and update the end point list automatically

 -  Michele

[Adrian Gropper]

Thank you Isaac!!!! This is good work on top of wonderful work. We're on a roll.

For our next act, can you make public the criteria open.epic uses to decide if it will register an app? I understand that you require a verified name associated with a valid credit card. Is there anything else you can mention or some document?

Adrian

[Michele Mottini]

Related: apparently HL7 is working (or planning to work) on a FHIR end points registry 

  - Michele

  CareEvolution Inc

[Adrian Gropper]

All,

How much of the process of registering an app do we want to make consistent across apps labeled SMART?

App developers and would-be-users (patients as well as clinicians) have to deal with both EHR vendors and individual hospitals. I imagine both the vendors and hospitals want to be able to differentiate themselves and that could be reflected as differences in the app registration process. On the other hand, these process differences complicate both developer and user adoption of SMART. 

How do we design best-practice for documenting the process by which an app is registered by whatever EHR + Hospital duo the app developer and app user are faced with?

Where should we discuss this? 

Adrian

On Wed, Jun 28, 2017 at 9:55 AM, open.epic - Inquiries <op...@epic.com> wrote:

Hi Adrian,

 

We don’t have an “approval” process for apps registered through open.epic. The only requirements for dynamic registration are:

 

-          Provide Valid credit card (no charge)

-          Agree to Developer Terms of Use

-          Provide basic info

o   Contact info

o   Application website

o   Public Documentation website

 

Thanks!

Richard Thomas

Epic|Integration Engineer

Open.Epic

[Travis Cummings]

Hi Adrian,

We have had some discussion around standardizing the app registration process on this Zulip channel:

stream:smart topic:SMART+App+Registration

We came up with a manifest.json proposal that would allow a hosted app (or an app artifact) to declare several of the values required for registration:

https://bitbucket.org/hspconsortium/registration

Within the apps at HSPC, we have used this manifest.json in several of our hosted apps.  Here is an example of the bilirubin-risk-chart manifest:

https://bilirubin-risk-chart-test.hspconsortium.org/.well-known/smart/manifest.json 

Is this the sort of registration information you are looking for?

Travis

[Adrian Gropper]

Hi Travis,

Thank you for pointing out HSPC. It's a very good start because it's based on Dynamic Client Registration but it supports too many options relative to what I'm looking for.

My focus is on patient-directed access to a FHIR API per the API Task Force. To paraphrase the use-case, (1) a patient can direct access by _any_ client, (2) a resource server can block access by a client only if it threatens the security of other patients - for example through a denial of service attack, and (3) a resource server can block access by a client for other reasons by way of warning the patient that they believe the client is risky, but if the patient insists on registering that client anyway then the resource server has to remove the block. 

My goal is to improve the user experience for patients by documenting best-practice for access to a SMART on FHIR API under patient-directed exchange. Ideally, the patient should have exactly the same user-experience regardless of which EHR vendor or hospital is the resource server happens to hold their records. Unlike a patient portal where the user experience is differentiated on a vendor and / or hospital basis, the patient experience for API access should be differentiated at the app level and not on the basis of EHR or hospital policy and have as little to do with the specific patient portal as possible. 

Mapping the API Task Force use-case into SMART on FHIR, the patient would (a) choose an app as the client independently of any particular provider relationship, (b) search for their provider in the app, (c) provide their portal user-id and password as part of the dynamic client registration process for the app, (d) accept a default scope to access all data under their right of access and a default refresh token for a year. That's it. Steps (b-d) would be repeated for any other providers.

How the patient gets portal access credentials to use in step (c) is out of scope for the process I'm hoping to document. It obviously gets into patient ID and identity verification issues that have nothing to do with SMART on FHIR. 

For some combination of apps and resource servers a warning message might be issued in step (d) per the API Task Force recommendations. I'm hoping the best practice we document makes these messages as uniform and useable as possible but that's just a nice-to-have once patients understand they have a right to connect any app.

I would note that the current open.epic is well along to meeting the requirements of the API Task Force. (i) The client registration endpoint is public and accessible to any app developer or patient. (ii) The app registration appears to be open to anyone with a major credit card without any review of the app itself. (iii) Patient portal credentials are all you need to register the client and access the API.  (iv) There do not appear to be any restrictions on the scope of access. The two major issues remaining are (v) implementing Dynamic Client Registration and, (vi) Issuing refresh tokens for a year by default (or whatever a patient might specify if that option is offered).

My question is: Where should we discuss and document best practice for (i) through (vi) so that patient-directed access becomes a uniform user experience?

Adrian

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhir+unsubscribe@googlegroups.com.

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

[Zafar Ullah]

Hi All,

I am new to open.epic.com, i wan to use oAuth, created MyApp at https://open.epic.com/MyApps, when i try below given url to get the authorization code, i always get the html. Please help and share any tutorial which gives step by step instructions.

https://open-ic.epic.com/argonaut/oauth2/authorize?response_type=code&client_id=bb789953-b23b-4d88-ad2f-1e162eecec0b&redirect_uri=https://localhost/fhir-app

the html is like

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr" >

    <head>

        <meta http-equiv="content-type" content="text/html; charset=windows-1252" />

        <meta http-equiv="X-UA-Compatible" content="IE=9" />

        <title>MyChart - Would you like to allow FHIR to access your account?</title>

        <link href="/MyChart/favicon.ico" rel="shortcut icon">

        <script src="/MyChart/Scripts/External/jquery-1.7.1.min.js" type="text/javascript"></script>

        <script src="/MyChart/Scripts/WP.Utils.min.js" type="text/javascript"></script>

        <script type="text/javascript">

if (typeof WP === "undefined") { WP = {}; }

WP.myPath = "/MyChart/";

</script>

        <link type="

[Wasif Munir]

Hi,

It's been more than 5 years since your last post, the idea of having a uniform user experience for a patient and a provider is the biggest problem in US healthcare, just curious to know how you have solved this problem so far and how SMART on FHIR have evolved to solve it. 

I am confused about a few basic use cases, anyone could help.

1) For Patient Apps: Do all major EHRs have enabled access to their patients for FHIR servers through their patient portal credentials, which means a patient can log in to their patient portals and at the same time access the Hospital/EHR's FHIR server with the same credentials? What is the best practice? 

2) For Provider Apps: if a practitioner wants to access their patient's data from their own Hospital/EHR system then they could use their Hospital/EHR’s system credentials to access their Hospital/EHR’s FHIR Server, or do they need to follow a separate signup process to get a separate credentials to get data through FHIR server?

3) For Provider Apps: if a practitioner wants to access their patient’s data from a different Hospital/EHR then which signup process does the practitioner follow to get credentials to access data from the FHIR server?

I am assuming the developer portal credentials couldn’t and shouldn’t work to authenticate to the FHIR server to get the patient’s clinical data.

[Josh Mandel]

(1) indeed, in the US market every certified EHR needs to support patient access using SMART on FHIR, offering an API into at least the US Core Data for Interoperability. Patients have credentials which are typically used for accessing an online portal as well as authenticating to authorize the launch of a SMART app.

(2) There is an analogous story for provider facing apps. On the technical protocol level, the flow looks just the same as (1). As a matter of organizational policy, healthcare provider organizations generally do not allow individual providers free rein to connect any apps they choose. Instead, the organization will typically enable some explicit set of apps with whom they have a business relationship, and then healthcare providers can run those apps within or next to the EHR. So that's one level of filter. But within this set of org-approved apps, when any specific app launches, it's still with an OAuth authorization from the end user, who has a session that's authenticated by their EHR credentials (but typically clinicians aren't asked to explicitly approve each launch; instead, most EHRs will automatically approve based on organizational policy, to save time/clicks).

(3) A provider-facing app can launch within the context of an EHR UI ("EHR Launch ") or in its own UI ("Standalone Launch").  In either case, SMART doesn't model the concept of "a different hospital"; as far as the app is concerned, it's launching against a single FHIR server where the end user must have appropriate access to authorize the launch. So the process for providers to acquire credentials is identical to (2).

In general, you're correct that developer credentials aren't sufficient to access clinical data. If you're building a user facing app, you launch with launch with authorization from that user.

If you're building a headless service that a healthcare organization wants to integrate directly, you might instead register a "backend service" (see https://hl7.org/fhir/smart-app-launch/backend-services.html). In USA. certified EHRs need to support backend service authentication at least for access to bulk data export, but you need organization level buy-in to connect such a service.

To view this discussion on the web visit https://groups.google.com/d/msgid/smart-on-fhir/d2b07946-538f-49d5-b3b4-8b527ca4a655n%40googlegroups.com.

[Adrian Gropper]

From my perspective, SMART on FHIR has been a success but we're still a long way from enabling meaningful medical practice innovation. There are no examples I know of a patient-centered and patient controlled health record that licensed practitioners and researchers can use. 

What we still have is separate, institutionally controlled silos for patients and licensed practitioners. Even though we recognize the importance of social determinants of health and increasingly sophisticated wearables, these are still not integrated into a patient-centered and institution-neutral record that anyone can use, based on their credentials, and patient authorization. With the exception of the recent introduction of Apple Health sharing with EHRs using SMART on FHIR, health information exchange, including TEFCA, still depends on "probabilistic" patient matching instead of patient authorization. Even with all of the progress around SMART, do patients and physicians have any more transparency when it comes to the costs and value of the medical services they provide? Research use of records is still siloed away from clinical use.

The potential benefits of comprehensive networked health records become even clearer as we introduce AI and ML. Who benefits from the learning value of every patient-clinician encounter? The patient? A patient group? Open medical science? Patients in other countries? Right now, the model is proprietary, branded AI outside of either patient or physician control.

SMART is a qualified success, but it's still all about the money. As we see increasing costs and increasing activism by clinicians across most aspects of health care, the impact of digital transformation is not looking good.

Adrian

To view this discussion on the web visit https://groups.google.com/d/msgid/smart-on-fhir/CANSMLKHDkDt97TsnrhsHFbtdd324kni7d9CizaRLYibTbwRHJw%40mail.gmail.com.

[Grahame Grieve]

Hi Adrian

From my perspective, SMART on FHIR has been a success but we're still a long way from enabling meaningful medical practice innovation. There are no examples I know of a patient-centered and patient controlled health record that licensed practitioners and researchers can use. 

Not in USA, that is. But they only exist in other countries because institutions have decided to set them up, and a few have, with variable levels of success

Grahame