Endpoint software requests that FHIR transaction be sent through service bus from which patient satisfaction surveys will be generated. Source for this data will be parsed through an integration engine from multiple formats (various HL7 v2 and flat file .csv primarily). Result transaction should include:
Meta data about the original source (sender, time received and so forth)
A data set that will contain derived values based on business rules to designate the type of outbound survey and ID according to location and patient type.
Items from clinical context (patient, providers, encounter information etc)
I feel like this is a Bundle of type ‘message’ or ‘transaction’ with resources for the clinical items and a message header. Where would I build the sending meta and the derived values? The meta data type in the message should be meta about the message I am sending. Do the details of the originating message seem like they should go into a different place or are they also meta? Do my derived values need to go into some kind of extension or would they be appropriate to place in tags?
I am thinking something along these lines:
Bundle
MessageHeader
Patient
Encounter
Practitioner
Has the endpoint software provided any indication of what they want the FHIR instance to look like? That’s your first consideration. If there isn’t a need for routing and the receiving system doesn’t care what they take in, you might consider using a custom operation rather than a FHIR message as it could be lighter-weight.
What metadata about the originating source data needs to be conveyed as part of the transaction?
For the originating message, I will want to relay the sending source, the time/date it was received, the type of data it was received in, and any unique identifier the sender generated. For HL7 2.x sourced messages it would be from the contents of the MSH segment generally. But this is data on top of meta about the message/transaction I am creating and sending. I am still not entirely clear as to which bundle type this will be. On the one hand it is basically a message, but on the other it is specifically transactional with the intent of triggering the release of a patient experience survey.
I guess at the end of the day even though 90% of what I build is mapped/normalized from the source, I am still sending a unique generated message of my own with derived values that is intended to perform a specific function. So architecturally, metadata about the originating message belongs in its own space and not in the meta of the message I am generating. It’s just data.
So thinking about the overall data structure, it’s basically 3 buckets:
meta and data about the message I am sending:
timestamp, generated UID, and a couple of derived fields from business rules such as intended client IDs and survey type designators.
information about the source message:
Sending system, source software, timestamp, unique ID if any, source message type.
Standard FHIR resources derived from incoming message data:
Patient data
Care Team Physicians
Encounter data
Possible inclusion of Payer and Condition information if available
All of the stuff in the 3rd bucket seems pretty self evident for FHIR resources, and the resources themselves have great predefined structures for the base data as well as sending things like human readable content that our partner system wants such as formatting the names out to a standard salutation.
As far as the lift on creating a FHIR message, the engine will actually make that fairly easy. Once I do the data extraction and formatting, it is simply a matter of mapping those variables into the engine’s predefined R4 message definitions. That will be a breeze. It’s defining the right FHIR message to use that is hard here.
I may be splitting too many hairs on the first 2 parts because in the end they are only a small part of the content. I just want to get this fairly close to right early because we have 100+ clients to onboard with this process over the next couple of years and I don’t want to have to go back and change anything fundamental 50 builds in.
Information about the source would probably be shared in the form of Provenance - it would indicate the source of the original data. The specific request to seek completion of a survey would be Task (one per survey). Message or custom operation would be equally viable. The former is heavier, but if the system already supports FHIR messages, they could re-use some existing infrastructure. Messaging also may make it easier to have an asynchronous response if needed. If you’ve got a query interface, you could actually just use REST to post the Tasks saying “please generate this survey” and point to the Encounter, Patient and other data from the Task - either using standard relationships or inputs. The Provenance would link to the Task and possibly other information. However, it would be necessary for the system asked to perform the Task to be able to query the linked information. The REST-based approach has the benefit of not requiring custom code to handle this particular type of request, nor to modify it if the set of relevant information evolves.