Our organization is implementing a clinical repository that implements FHIR, i.e. by using SmileCDR/HAPI . One of the planned uses of this is to feed data to a particular application program, where the data feed has to be structured in atabular format, and each table of data fed to that application program may need to include data from different types of resources.
My sense is that we could use FHIR’s bulk export capability to retrieve the data, build a staging layer with a table for each table type, and then parse the exported data into the appropriate tables of the staging area. However, I am wondering whether we could instead create a set of extended operations, with one extended operation for each of the different table types, and then return the data as a table, albeit formatted in JSON.
I have looked at the documentation of the extended operation capabilities, both in FHIR and in HAPI. What’s not clear to me is whether I could return a custom JSON object, containing the table, or whether I need to return an JSON object based on an existing resource type.
If anyone understands the extended operations capability, I would really appreciate your feedback on this question.
well, I can sure say that the standard doesn’t describe anything like what you’re talking about. The nearest it comes to is the way it describes to use graphql on top of the underlying data access methods. And you… could… use graphql for this use… but it sounds like you need something more transformative than graphql alone, and we haven’t really worked on a pipeline like that. It’s not that we don’t think you should do thing like this, it’s just that there hasn’t been much interest in standardizing this kind of pipeline - everyone wants their own pipeline. (you could try using CQL too, but it’s pretty much in the same boat)
And we haven’t described anything like this with the bulk data interfaces - there, the focus is just getting the data, on the assumption that you’re going to run your own pipeline on them afterwards.
All this is to say: it’s unlikely that HAPI will support anything like you want out of the box. On the other hand, HAPI is open source… so it can do whatever you make it do
With an operation, the result must be either a FHIR resource or a Parameters instance. So it can’t be custom JSON. You could have a parameter that was a string that contained custom JSON (though you’d have to do some un-escaping). You could also return an Attachment which contained base64-encoded JSON. The only way to return true custom JSON would be graphql. In principle, you could combine the approaches - custom operation to return your data as a parameters instance and then GraphQL to extract the desired JSON. You wouldn’t even need multiple operations, as you could pass in a parameter indicating the ‘table’ you were interested in.
The base question is - what are your objectives in trying to do this with a FHIR stack as opposed to just writing some code to spit out what you want at a custom endpoint. You’re not exposing FHIR, so wrapping it up in a FHIR façade isn’t necessarily buying you much.
We would like to be able to use a FHIR based clinical data repository (Smile CDR) to feed a third party program which we will then use to create synthetic patient data. The feeding process involves about a dozen tables of data. Each table to be fed to the third party program involves fields from several different types of FHIR resources. The data will be fed at regular intervals of perhaps one month and involve a lot of data.
Given the apparent ease with which java seemingly can be used to pull specific fields from specific resources in HAPI/Smile CDR, it occurred to me that it would be relatively easy to format the data in the HAPI/Smile CDR environment. FYI, the actual format used by the third party program is somewhat arbitrary; it could be json, csv, fixed column formatting, xml, . . . But it appears to me (and I may be wrong) that in order to do this you need some way of triggering the programming to run, and a mechanism for sending the results to third party program.
Perhaps naively, I thought that extended operations could be used to trigger this process. Selectively copying from the FHIR documentation, Operations - FHIR v4.0.1
*** Operations are appropriately used where the server needs to play an active role in formulating the content of the response, not merely return existing information**
*** Operations have the following general properties:**
*** * Each operation has a name**
*** * Each operation has a list of ‘in’ and ‘out’ parameters**
*** * Parameters are either resources, data types, or search parameters**
*** * Operations are subject to the same security constraints and requirements as the RESTful API**
*** * The URIs for the operation end-points are based on the existing RESTful API address scheme**
*** * Operations may make use of all types of resources existing in the repository**
*** * Operations may be performed on a specific resource, a resource type, or a whole system**
Our major constraint on this is that we wish to provide large quantities of this data, so using rest based operations to pull data from one resource at a time seems likely to be a very slow process.
Lloyd - you mention using custom endpoints. I haven’t seen any documentation for doing that. Can you point me towards some?
Operations are a way to expose FHIR data in a custom way. If the data you’re sharing isn’t FHIR, then just build a custom API. No need for it to be FHIR at all (either in how it is invoked, what arguments it takes or what the data looks like.) There’s no documentation in FHIR about it because it’s outside FHIR entirely. Just expose some sort of custom URL that when a system executes a GET against it causes the relevant CSV or Zip of CSVs to be returned.
Thanks for getting back to me. The data is FHIR data, and our goal is to expose it in a custom way. In addition, we would like to take advantage of the security and transport mechanisms of the FHIR environment.
So, am I correct in understanding is that this is a reasonable use of extended operations?
FHIR doesn’t define security - we leverage basic web security mechanisms (TLS, OAuth, etc.). And for transport, we just use HTTP. What we do is define HTTP conventions for retrieving FHIR data. I suppose if you really want to expose what you’re doing over FHIR (e.g. so it shows up in your CapabilityStatement), then you could define an operation that returns a single Binary resource (which would happen to be a CSV file).
You absolutely can. Transport is HTTP and security is (typically) TLS and OAuth - and those are useable for any sort of RESTful interface, not just FHIR.