I am working for an organization that uses a combination of flat file import and real time HL7 2.x messaging to produce patient experience surveys.
We are beginning to get feelers from some clients about switching to an API based system for triggering surveys. Would this kind of data exchange fit any of the current FHIR profiles?
Essentially we receive fairly boilerplate ADT type data (Patient, Encounter, Coverage and Care team data). How would something like this look if we exposed an API in our engine so that clients could send us messaging to trigger surveys directly?
Would we be looking at some type of Bundle (message or transaction)?
We are just considering our options for future enhancements and capabilities. The interest in this is very preliminary at this point. But our clients would like us to lead on the messaging, so if this is something that we should be looking to use FHIR for it would be worth our effort to develop a profile.
FHIR provides a number of approaches that could be used to trigger surveys - FHIR-based messages, FHIR operations, notifications from FHIR subscriptions or simple REST creates and updates. Which makes sense sort of depends on what type of data needs to be sent, whether routing is involved, and whether this is a custom interface or is something where you’re going to need to drive off existing interface capabilities. A complete decision tree of options is here: HL7.FHIR.US.DAVINCI-HREX\Approaches to Exchanging FHIR Data - FHIR v4.0.1
Thank you for answering and for providing the very useful decision tree link. The real world workflow that triggers surveys will likely not change, that is the end of some type of provision encounter, be that a discharge or an order fulfillment, or transfer. The client will message us when they want a survey to be generated.
Data elements are fairly basic:
Patient - Demographics with an emphasis on telecom and addresses.
Encounters - Very important to have location, service, and date details (or Appointment details)
Practitioners - Id, and names for the most part, but generally the entire care team
Procedure or Diagnosis information - basic codes and descriptions here
Payer/Guarantor information - basic details
Provenance/metadata - Sending system information and values derived based on business rules (for example, a combination of location, service code, and patient age will generate survey xyz.)
We’ll derive some values from the information sent, such as human readable names and identifiers for survey types to generate. Largely though, the data out to our survey solution system will be directly derived from the sender’s data baked into 150-175 potential fields.
My instinct is that this is a transaction type of bundle since it is literally a message that says “generate a survey based in this data and agreed on business rules”. But the decision tree, when I follow it, leads me more to a message type bundle. So I don’t know how much distinction really needs to be made there.
Transaction would mean you’re asking the recipient to create or update resource instances corresponding to the data you’re sending - which isn’t what you want. I think you’ve got 3 options:
a custom operation that takes a Bundle or perhaps multiple parameters to pass relevant resources or data elements
a custom message that is a Bundle containing relevant resources with an appropriate event code
a subscription notification which either embeds a Graph of information in a Bundle or allows the recipient to query the relevant information on receipt
Note that #3 doesn’t actually say “please generate a survey”, that would be a decision the recipient would decide on based on the data received. The other two would be an explicit “please generate a survey”.
#2 adds a bit more overhead than #1, but allows routing and simpler asynchronous response. It may allow leveraging existing FHIR messaging infrastructure.