Stream: implementers
Topic: EPIC FHIR rest API
Ani Matevosyan (Mar 05 2022 at 18:47):
Hi all, is it possible to send data to epic via a rest API and not via HL7 messages ?? I see the FHIR api is only for getting data, but is there a way to send data to epic with API calls? I can't figure this out, could you help me? thanks a lot.
Lloyd McKenzie (Mar 05 2022 at 19:16):
Go to https://fhir.epic.com/ and look for any resource that says "create" or "update" - those are write operations that the Epic interface supports. Their interface (and the interfaces of most EHRs) continues to evolve over time to have additional capabilities to both read and write data.
Ani Matevosyan (Mar 05 2022 at 19:49):
thank you very much @Lloyd McKenzie but I don't find any "create" or "update" operation for the surgical cases, only CDS Hooks that haven't URL for calling (seems are related to HL7 messages )
Lloyd McKenzie (Mar 05 2022 at 19:59):
There is Create on AllergyIntolerance, Communication, Condition, DocumentReference, Observation, Patient and QuestionnaireResponse that are not CDS-hooks. Several of these would be relevant for surgical use-cases. What you don't have (yet) is Procedure or Encounter. You may be stuck using HL7 v2 or a custom API for those, at least for now.
Ani Matevosyan (Mar 05 2022 at 20:15):
ok, but I must put surgical cases info in epic, is there another way to do it excepting the hl7 messages ( using app orchard or some other thing) ??
Lloyd McKenzie (Mar 05 2022 at 20:16):
You'd have to reach out to Epic on that.
Ani Matevosyan (Mar 05 2022 at 20:18):
ok, thank you
Cooper Thompson (Mar 07 2022 at 15:29):
We can handle the Epic-specific question on open@epic.com, but more generally, "writing" a surgical case involves:
- match or create a patient
- match or create an encounter
- match or create a surgical case (probably appointment)
- if the surgical case is completed, then post the log of that case as a Procedure (or set of procedures)
- if you are tracking billing, then post charges (ChargeItem)
- if the surgical case involves anesthesia, then document that, and submit anesthesia charges (which are known to be super complicated, and I've honestly no idea how to represent that in FHIR. Probably ChargeItem with a ton of extensions).
All this is to say: spoiler alert: we don't have FHIR support for writing surgical cases into Epic.
Brendan Keeler (Mar 12 2022 at 05:34):
Double spoiler: There isn't a way to create a surgical case into Epic via HL7 either
Brendan Keeler (Mar 12 2022 at 05:35):
Although there is a way to update existing cases originally created in Epic
Ani Matevosyan (Mar 14 2022 at 11:58):
Thank you very much for your explanations
Cooper Thompson (Mar 14 2022 at 13:45):
Also, on a more philosophical point, I'd argue that a REST API is not the right way to push surgical cases into an EHR Using FHIR Messaging or something like that (maybe transactions) seems better. I say that because the matching logic (patient, encounter, case) is really important to do right so you don't junk up the chart. I'm not saying "you" specifically would junk it up - but just that if we have a wide range of apps doing matching in different ways, it would get really hard to manage. Instead, we'd rather the server handle all that matching in a consistent way. I suppose we could use $match (for patient) and create similar options for Encounter and all the other records that need matching, but you still have the problem of doing the create, then possibly rolling back if you fail later. I.e., if you fail to create the case, in theory we'd want to roll back any encounters or patients you created so those aren't lingering, but then you run into issues trying to delete stuff since EHRs normally won't let you do that. So really you need to be 100% sure that everything will file before you create anything, which you can't really do with a REST API. It seems much simpler to just send all the information you have a case and let a server match/create/update/delete everything based on their consistent set of business rules.
Cooper Thompson (Mar 14 2022 at 13:52):
Also, normally an EHR will want to trigger a bunch of business processes when you "write" a case. Stuff like triggering charges, tracking case report requirements, etc. Triggering that based on a RESTful write is very tricky. We'd really want an event-based trigger of some sort. In the true REST model, we'd make the case submitter do all of that, but I haven't seen most apps have the appetite to track and notify on all the business processes that need to happen on the backend.
Ani Matevosyan (Mar 14 2022 at 14:40):
ok @Cooper Thompson thank you
Vadim Peretokin (Mar 14 2022 at 14:43):
@Cooper Thompson what's your take on using a transaction to alleviate the consistency concerns?
Cooper Thompson (Mar 14 2022 at 14:59):
A transaction with normal REST API operations isn't enough to handle the matching logic. Transactions still rely on clients to own the matching logic and then do create/updates with the relevant references. I don't think you can really embed $match operations in a transaction (but maybe I'm wrong?). But even if you could embed operations, you still need reference updates to happen on sibling interactions in the transaction.
For example, for the "encounter matching" logic, you'd need to somehow embed this logic in the transaction:
- Search for existing encounters
- Review the the results, pick the "best" one based on whatever your business logic is.
- Possibly create a new encounter if you don't find a matching encounter (or if you know ahead of time you need a new encounter)
- Submit the subsequent case create interactions with references to that "best" encounter.
-- OR --
- Invoke an Encounter.$match operation (which could be designed create an encounter if needed).
- Use the encounter returned from that as the reference in your subsequent case create interactions.
As far as I know, a transaction can't handle taking the output of one operation in the transaction and dynamically updating references in subsequent operations in the same transaction.
Thus why I prefer messaging (or possibly operations). You just send the info you have, and the server applies it's own business rules to do matching and everything else.
Cooper Thompson (Mar 14 2022 at 15:15):
Also, I don't know of a great way to submit an "event" using a transaction. I suppose maybe MessageHeader.create? Though that seems very odd. Maybe other folks have ideas of how to trigger an event RESTfully (/transactionally).
Vadim Peretokin (Mar 14 2022 at 15:24):
Yep makes sense, thanks for the answer.
Cooper Thompson (Mar 14 2022 at 15:29):
I guess I should point out that if you have an end user involved that is picking the right patient/encounter/etc., then REST API is much more reasonable (but you still have the event notification problem). But I inferred that your surgical case creation was sending everything after-the-fact and didn't involve end user selecting everything they needed for the case submission.
Josh Mandel (Mar 14 2022 at 15:52):
Also writing data in various draft states can be a technique to prevent triggering downstream logic too early. And as Cooper mentioned, transaction bundles with standard semantics rather than a dense set of special purpose messaging bundles.
Brendan Keeler (Mar 14 2022 at 17:04):
I was told that REST solved all problems, though
Brendan Keeler (Mar 14 2022 at 17:04):
I am shook
David Pyke (Mar 14 2022 at 17:05):
Most of North America just changed to Daylight Saving. How can REST solve that?
John Moehrke (Mar 14 2022 at 18:23):
if you sleep in (REST) you are not bothered by needing to get to meetings that have already happened.. problem solved.
Last updated: Apr 12 2022 at 19:14 UTC
