FHIR Chat · Publisher: Epic and Epic Sites · smart/scheduling-links

Stream: smart/scheduling-links

Topic: Publisher: Epic and Epic Sites

Josh Mandel (Apr 12 2021 at 15:08):

@Cooper Thompson are you working with the teams at Mercy and Ochsner to get $bulk-publish endpoints in place? (And if not, let me know if there are steps that would help get things moving.)

Cooper Thompson (Apr 12 2021 at 15:38):

I am working with Mercy. I will reach out to Ochsner and see where they are and get things moving.

Josh Mandel (Apr 12 2021 at 15:41):

Excellent! (I sent emails to folks in both orgs and cc'd you, too.)

Cooper Thompson (Apr 12 2021 at 22:52):

I do have our fhir.epic.com sandbox set up with our $bulk-publish endpoint: https://fhir.epic.com/interconnect-fhir-oauth/api/epic/2021/Scheduling/Utility/covid-vaccine-availability/$bulk-publish. This doesn't require any authentication, however you do need to provide a custom Epic HTTP header with a client ID. I've registered a client ID specifically for the connectathon that all participants can use. This is the http header:
Epic-Client-ID:b7ff78db-4a95-4098-8183-2424b980a1f3

Josh Mandel (Apr 12 2021 at 22:53):

Cool! Will you add these details into the sign up sheet?

Josh Mandel (Apr 12 2021 at 22:54):

(https://docs.google.com/spreadsheets/d/1Fh0zwCjKYh4D-Mp1k5uxzINh6GG0yI1ezko49VaJV2c/edit)

Cooper Thompson (Apr 12 2021 at 23:01):

Done

Josh Mandel (Apr 13 2021 at 02:47):

Quick note @Cooper Thompson -- looks like your Schedules have a double-slash (//) instead of a single when they reference Location (Schedule.actor.reference). (Now I'm curious if the validation tool picks this up.)

$ curl -s  -H 'Epic-Client-ID:b7ff78db-4a95-4098-8183-2424b980a1f3' 'https://fhir.epic.com/interconnect-fhir-oauth/api/epic/2021/Scheduling/Utility/covid-vaccine-availability/WI/Schedule' | jq
{
  "resourceType": "Schedule",
  "id": "no5eEpXeqGRlxmYRff0DtmQ1S6E11BU353w1FJkbOqc=",
  "actor": [
    {
      "reference": "Location//OJ7KdmjeqoVUl2njbHkzA=="
    }
  ],
  "serviceType": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/service-type",
          "code": "57",
          "display": "Immunization"
        },
        {
          "system": "http://fhir-registry.smarthealthit.org/CodeSystem/service-type",
          "code": "covid19-immunization",
          "display": "COVID-19 Immunization Appointment"
        }
      ]
    }
  ]
}

Robert Scanlon (Apr 13 2021 at 02:58):

I just pushed an update our tests so the user can provide a custom header (and the test flags a warning because it violates a 'should' requirement regarding open access).

Robert Scanlon (Apr 13 2021 at 02:59):

Turns out this passes the cross-resource reference check because the ID of the location resource itself starts with a "/".

Josh Mandel (Apr 13 2021 at 03:01):

Thanks for adding this feature @Robert Scanlon -- and good call on the source of the bug. Glad this got caught somewhere!

Robert Scanlon (Apr 13 2021 at 03:04):

Surprisingly (to me) though, the HL7 FHIR validator doesn't seem to flag this id as being invalid? "/" isn't valid for the id data type, right? https://www.hl7.org/fhir/datatypes.html#id

Josh Mandel (Apr 13 2021 at 03:06):

Agreed, invalid! Does Inferno have its own checks for Resource.id, or did it miss this by relying on the FHIR validator?

Josh Mandel (Apr 13 2021 at 03:06):

(will you file a bug on the HL7 FHIR validator?)

Robert Scanlon (Apr 13 2021 at 03:12):

This instance of Inferno is configured to use the HL7 validator for resource/profile-level validation, because the HL7 validator is currently more fully featured than our Ruby validator. We'll look at it closer tomorrow to make sure this isn't on the Inferno side somehow. I find it surprising that the HL7 validator would miss this. FYI @Michael O'Keefe

Robert Scanlon (Apr 13 2021 at 03:15):

It did pick up the fact that Location.address is an Array instead of an Object though, so that needs to be fixed.

Michael O'Keefe (Apr 13 2021 at 12:10):

@Robert Scanlon I just tried validating that Location object against our HL7 validator service, and also the latest Validator JAR build from org.hl7.fhir.core. Neither of them picked up the leading slash in the Location ID as an error. Sounds like it's a bug with the org.hl7.fhir.core validator code

Michael O'Keefe (Apr 13 2021 at 13:55):

Issue posted here: https://github.com/hapifhir/org.hl7.fhir.core/issues/476

Cooper Thompson (Apr 13 2021 at 13:58):

I'm looking into the // Location reference issue. We are using a different ID generation scheme than we do for our normal FHIR API, so it might be that it can sometimes generate an ID with a /. Anyway, I'm looking at it.

Cooper Thompson (Apr 13 2021 at 16:12):

I just pushed a fix for the /-in-FHIR-ID issue to the fhir.epic.com sandbox.

Josh Mandel (Apr 13 2021 at 16:19):

Re: booking deep links, does the booking portal have any support for incoming context (appointment types, date, etc)?

Michael O'Keefe (Apr 13 2021 at 16:20):

@Cooper Thompson is there a caching delay before the new ID goes live? I'm still seeing the old "id": "/OJ7KdmjeqoVUl2njbHkzA=="

Josh Mandel (Apr 13 2021 at 16:24):

I'm seeing the updates.

Josh Mandel (Apr 13 2021 at 16:25):

$ curl -s  \
-H 'Epic-Client-ID:b7ff78db-4a95-4098-8183-2424b980a1f3' \
'https://fhir.epic.com/interconnect-fhir-oauth/api/epic/2021/Scheduling/Utility/covid-vaccine-availability/WI/Location' | \
jq | \
head

{
  "resourceType": "Location",
  "id": "-OJ7KdmjeqoVUl2njbHkzA",
  "name": "EHS Covid Vaccination Clinic",
  "telecom": [
    {
      "system": "phone",
      "value": "000-555-1234"
    }
  ],

Michael O'Keefe (Apr 13 2021 at 16:25):

Weird. For some reason, this is what I'm seeing:

Michael O'Keefe (Apr 13 2021 at 16:25):

-H 'Epic-Client-ID:b7ff78db-4a95-4098-8183-2424b980a1f3' \
'https://fhir.epic.com/interconnect-fhir-oauth/api/epic/2021/Scheduling/Utility/covid-vaccine-availability/WI/Location' | \
jq | \
head
{
  "resourceType": "Location",
  "id": "/OJ7KdmjeqoVUl2njbHkzA==",
  "name": "EHS Covid Vaccination Clinic",
  "telecom": [
    {
      "system": "phone",
      "value": "000-555-1234"
    }
  ],```

Michael O'Keefe (Apr 13 2021 at 16:26):

Could be a caching thing on our end. I'll try again later

Cooper Thompson (Apr 13 2021 at 16:27):

We have two load balanced servers. It's possible one of them didn't get the DLL update. I'm re-pushing it to both now just to be sure. We shouldn't be sending cached content from our end, and I wouldn't expect curl to cache.

Cooper Thompson (Apr 13 2021 at 16:28):

Ah - looks like one of our load balanced servers didn't get the update. Standby.

Cooper Thompson (Apr 13 2021 at 16:31):

@Michael O'Keefe - try now.

Michael O'Keefe (Apr 13 2021 at 16:32):

@Cooper Thompson tried again, the IDs look correct now. Looks good!

Robert Scanlon (Apr 13 2021 at 17:01):

There are three other issues @Cooper Thompson we picked up during validation. Since it isn't obvious based on the message, the Slot.start/end issue seems to be because no timezone was provided.

JT Bennett (Apr 15 2021 at 20:12):

@Josh Mandel worked with the BSMH team and @Cooper Thompson , added our URL to the signup spreadsheet. Should be good to begin testing, let me know how else we can assist.

Cooper Thompson (Apr 15 2021 at 20:13):

@JT Bennett - I think there was going to be a downtime this afternoon though right?

Josh Mandel (Apr 15 2021 at 20:22):

Thanks @JT Bennett! @Cooper Thompson have you tried this through Inferno?

JT Bennett (Apr 15 2021 at 20:24):

Good point, @Cooper Thompson , my oversight - should be back up tomorrow AM @Josh Mandel

Josh Mandel (Apr 16 2021 at 21:26):

@Cooper Thompson can you help me debug the following?

curl -H 'Epic-Client-ID: b7ff78db-4a95-4098-8183- 2424b980a1f3'  'https://chperx-tst.health-partners.org/FHIRTST/api/epic/2021/Scheduling/Utility/covid-vaccine-availability/$bulk-publish'

I was thinking this would be all I needed but I'm getting a 404.

Cooper Thompson (Apr 16 2021 at 21:29):

@Josh Mandel - looks like an issue with the endpoint. @JT Bennett - I think this was the same thing Doug saw yesterday, where the re-write rule on the reverse proxy mysteriously disappeared. Can you have him check if it got deleted somehow?

Josh Mandel (Apr 21 2021 at 19:17):

@Cooper Thompson it looks like resources from https://chperx-tst.health-partners.org/FHIRTST still have ids with = in them -- is this a known issue?

Josh Mandel (Apr 21 2021 at 19:18):

Also, slot times are missing a timezone suffix (which FHIR's instant requires)

Cooper Thompson (Apr 21 2021 at 20:33):

Yeah, we have both of those as known issues (found during connectathon). The ID fix I have on fhir.epic, but we have more process to get that fix out to customers. We'll be working on a package for all the issues we found during connectathon after the connectathon closes.

Cooper Thompson (Apr 21 2021 at 20:33):

If necessary, I can push updates to fhir.epic, but not (quickly) to Ochsner or Mercy

Josh Mandel (Apr 21 2021 at 20:41):

Thanks. Any updates on Ochsner API availability?

Cooper Thompson (Apr 21 2021 at 20:52):

I think we're almost there...

Cooper Thompson (Apr 22 2021 at 14:20):

The Mercy endpoints is back up now. I've run the Inferno tests and there are some known failures. Epic will be doing a set of fixes based on stuff we found during connectathon. Some of those fixes I've pushed up to the fhir.epic sandbox already, but it takes longer to get those out to our sites like Mercy and Ochsner.

JT Bennett (Apr 22 2021 at 14:25):

Let me know if any additional failures (that are not expected) happen, happy to resolve quickly @Cooper Thompson @Josh Mandel

Rob Brackett (May 18 2021 at 16:55):

@Cooper Thompson I think either you or Nell mentioned on last week’s call that you were still working through whether this would be open-access for for hospitals using Epic. Are there any hospital systems that have it enabled already, and are any of them open-access?

In New Jersey, the state’s been trying to get all the right App Orchard stuff set up, but has had trouble getting it done (not sure what the hold-up is; someone else has been on that), and I’m wondering if this might be another, easier route to go if any Epic customers in NJ are already using it. (And nationally, USDR would love to grab whatever we can to make more broadly available in a combined data set.)

Cooper Thompson (May 18 2021 at 17:00):

We're still looking at our strategy. But regardless of what Epic decides to recommend, the ultimate decision will likely be up to our customers. That said, if there are any App Orchard or fhir.epic issues you need help with, I can definitely help with those.

Cooper Thompson (May 18 2021 at 17:01):

We had a round of fixes we needed to do from the connectathon a few weeks ago. We're just getting those out (dose number hung us up for a while). We'll likely not have any organizations live with PRD URLs until those fixes get deployed in the coming weeks.

Rob Brackett (May 18 2021 at 17:25):

:thumbs_up: thanks, that timeframe is helpful.

Last updated: Apr 12 2022 at 19:14 UTC