Stream: implementers
Topic: FHIR response for CommunicationRequest
Odd A. S. Dahl (Sep 05 2016 at 16:11):
We are creating a FHIR service for support sending of electronic communication objects, like SMS and e-mail.
It receives the CommunicationRequest object (POST), that contain the message and the communication type
(and other properties). This might be a basic question but I could not find documentation for the type of response the service can send back;
should it always be OperationOutcome, or would Communication or CommunicationRequest be usable? Should this be up to the implementers to decide, or is this predefined?
Lloyd McKenzie (Sep 05 2016 at 19:16):
It depends on how you're transmitting. If you're using pure REST - i..e. posting to [base]/Communication, you'll either get back a 201 response (Communication instance has been stored), or you'll get back a 4xx or 5xx error, possibly with an OperationOutcome, indicating that the instance wasn't stored. If you want to use an operation (e.g. posting to [base]/Communication$foo where foo is a defined operation), then you have the option of alternative responses. But at the moment, we don't have any operations defined for this purpose. You can define and use your own and/or submit change requests for some to be defined as part of the core specification.
Odd A. S. Dahl (Sep 07 2016 at 13:28):
OK, OperationOutcome is out of the question then, but we'll need to send back information about the instance id that was stored so I'll look into operations. I see that it is possible to define your own - hl7.org/fhir/operations.html: "Implementations are able to define their own operations in addition to those defined here. "
Thanks for the reply!
Pascal Pfiffner (Sep 07 2016 at 16:23):
If you only need the instance id, you will get that with a regular POST. You can look into the Location header that was returned or you can say that you want the created resource back (with a Prefer header of return=representation), which will also contain the created id. The FHIR libraries may already do that for you and update the instance object (the Swift library does).
Pascal Pfiffner (Sep 07 2016 at 16:24):
http://hl7-fhir.github.io/http.html#2.42.0.5.2
Odd A. S. Dahl (Sep 08 2016 at 06:30):
Thanks for the replies @Lloyd McKenzie and @Pascal Pfiffner !
We'll look into if we'll want to make it an operation, return the deafult HTTP with location, or if we'll leave it up to the requester to specify the Prefer return type in the header, or both (I know it should be supported accoring to the standard). With this information we have more options for this and future services we'll create.
Lloyd McKenzie (Sep 08 2016 at 20:37):
Using a REST "create" post vs. an operation invocation post is two different URLs and two very different things - no need to use the Prefer return type. In STU 3, I believe you can now use Prefer to indicate whether you want the created resource echoed back to you or not. And if there's a failure, you'll likely get back an OperationOutcome whether you want one or not. But there's no way to get a Communication back in response to a post of a CommunicationRequest unless you're using an Operation.
Paul Knapp (Sep 10 2016 at 19:01):
or conventional REST (request-response), or some other request-response style exchange.
Paul Knapp (Sep 10 2016 at 19:05):
You also haven't indicated whether you expect the exchange to be real time. If not then you can use a FHIR REST Create (receive the location and potentially an OperationOutcome in the return) and then poll via FHIR Search for a Communication resource which is the response to the CommunicationRequest.
It really comes down to the exchange pattern you need to support the business, in all cases the Communication and CommunicationRequest resources are the right ones to be exchanging.
Lloyd McKenzie (Sep 11 2016 at 14:25):
@Paul Knapp The answers above are all about what can be done within the context of FHIR. If you choose to step outside the FHIR framework, you can do what you wish. But within FHIR, if you post to [base]/CommunicationRequiest, you can't ever get back a Communication.
Paul Knapp (Sep 11 2016 at 16:11):
Correct, the FHIR REST framework doesn't provide a Response resource to the POSTing of a Request resource if POSTed to a [base url]/Request endpoint, but I never said it did.
I think that Odd is looking for ways to use FHIR in his solution. FHIR includes both content models are exchange methods, but use of the exchange methods is not required. Therefore, the exchange of FHIR content models via any exchange including one which may better suit a business need is not stepping outside the context of FHIR, but it is stepping outside the space defined by FHIR.
Lloyd McKenzie (Sep 11 2016 at 17:14):
Hi @Paul Knapp, to be FHIR-conformant, you must define what you do using the Conformance resource and you must adhere to the rules set in the spec around URL naming. Certainly you can take the FHIR schemas and pass around data however you like. But if you want to be conformant, then you need to do things the way the specification defines. Given that the specification defines a way to do what he envisions - passing in a CommunicationRequest and getting back a Communication, it sort of makes sense to try to do that in a conformant way.
Paul Knapp (Sep 11 2016 at 17:50):
This sounds like FHIR has been redefined to REQUIRE one to use one of the FHIR information exchange protocols if one wishes to claim FHIR conformance - which is a new assertion and one which was from the beginning strongly asserted not to be the case.
Following the URL naming is required if you use any protocol, FHIR or other, which specifies an URL naming requirement - so...?
Lloyd McKenzie (Sep 11 2016 at 18:25):
The base rule of FHIR conformance has always been: your system must have a Conformance instance that defines what it does, and the system must do what the Conformance instance says it does. Furthermore, interfaces defined by the specification are expected to be adhered to. So if you do a POST to [base]/Patient, you must behave as the FHIR specification declares. If you do a post to [base]/Patient_foo-bar, then (at least right now), the behavior is undefined and can be whatever you like - though you'd need extensions on the Conformance resource to define the nature of that behavior. (Which means it's a whole lot easier and more interoperable to use the Operation mechanism if you're doing HTTP.) And of course, if you're sending things over SMTP or SOAP or whatever, then things are totally unconstrained, though again, defining your behavior using the Operation mechanism at least gives you a standard way of specifying inputs and outputs.
Paul Knapp (Sep 11 2016 at 19:36):
Ok, so not saying that using FHIR described protocols is mandatory.
Lloyd McKenzie (Sep 12 2016 at 05:25):
@Paul Knapp I'm saying that if you want to call yourself FHIR conformant, you need to declare what you do in your Conformance instance. Outside of what that instance declares, you can do other things, but you can't claim they're FHIR conformant.
Odd A. S. Dahl (Sep 14 2016 at 06:51):
Great discussion, this helped me wrap my head around how we should implement FHIR services.
We decided to be compliant to the standard and return the CommunicationResponse object for the POST endpoint . It will support realtime message transfers, and in the future we'll also support scheduled message. We are also going to implement the solution @Paul Knapp described with a Communication endpoint where it is possible to get the status about the transfer, using the same ID that the CommunicationRequest request returns. This way the systems using the FHIR service can get the status of scheduled messages after they are sent. We also have default support for OperationOutcome on errors.
Lloyd McKenzie (Sep 14 2016 at 13:22):
@Odd A. S. Dahl I'm having trouble understanding your solution. You're planning to POST a Communication and synchronously get back either a CommunicationResponse or an OperationOutcome, is that correct?
Odd A. S. Dahl (Sep 14 2016 at 13:30):
The input POST message will be CommunicationRequest, and the response message will be the same. OperationOutcome will only be sent back if the message fails, e.g. failure in parsing the message according to the profile.
Lloyd McKenzie (Sep 14 2016 at 13:43):
ok
John Moehrke (Sep 14 2016 at 13:44):
IHE has used the CommunicationRequest and Communication in a profile out for Trial Implementation - Mobile Alert Communication Management (mACM) http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_mACM.pdf It leverages that this is a request for communication, allowing the actual communication to be over email, sms, iMessage, or even the ACM profile (using v2),
Mat Coolidge (Dec 18 2016 at 17:33):
@Lloyd McKenzie Can you explain what the difference would be between creating an operation outcome versus invoking an operation to a query?
Mat Coolidge (Dec 18 2016 at 17:38):
I want to return a bundle populated with a query of patients and their last taken vitals. Would I be able to do something like Patients/$operationName?_list=1234 ?
Grahame Grieve (Dec 18 2016 at 22:02):
I'm not sure that I follow this/
Grahame Grieve (Dec 18 2016 at 22:03):
there is a template for getting the last set of vital signs in the spec..
Grahame Grieve (Dec 18 2016 at 22:04):
hmm no
Grahame Grieve (Dec 18 2016 at 22:04):
@Eric Haas @Rob Hausam I thought we talked about this?
Eric Haas (Dec 18 2016 at 22:40):
@GG we did GFORGE #9964 but my staff is a bit behind. :-)
Lloyd McKenzie (Dec 18 2016 at 23:29):
@Mat Coolidge I'm not sure I understand what you mean by "invoking an operation to a query". Queries can be RESTful - do a GET on a resource endpoint and specify filter parameters; or you can define an operation that defines more complex behavior with a different endpoint.
Mat Coolidge (Dec 18 2016 at 23:37):
Like what Grahame had noted here http://www.healthintersections.com.au/?p=2464 I want to be able to search on the patient resources and return a group of other resources
Grahame Grieve (Dec 19 2016 at 00:15):
well, you can batch request, just like that
Grahame Grieve (Dec 19 2016 at 00:16):
GET [base]/Observation?patient=[id]&code[vital sign LOINC]&_count=1&_sort=-date
Grahame Grieve (Dec 19 2016 at 00:17):
one in the batch for each vital sign you want
Grahame Grieve (Dec 19 2016 at 00:18):
else see Eric's task, which deals with some of the issues
Mat Coolidge (Dec 19 2016 at 00:18):
We would like to be able to do a single request
Mat Coolidge (Dec 19 2016 at 00:18):
ok
Mat Coolidge (Dec 19 2016 at 00:20):
It would be nice to be able to do an operation like this for each patient in the query. http://www.healthintersections.com.au/wp-content/uploads/2016/02/simple_summary.txt
Mat Coolidge (Dec 19 2016 at 00:21):
the request might not be last N
Mat Coolidge (Dec 19 2016 at 00:22):
it could be everything since a date or any other query
Mat Coolidge (Dec 19 2016 at 19:16):
I beleive I now understand what you mean by Batch requests. I might have been confusing an operation (Questionnaire Populate) for a batch request. Where is the best place for examples of requests and responses of batches?
Mat Coolidge (Dec 19 2016 at 19:17):
Also would it be possible to "cache" a batch call to be rerun. In that I mean reprocessing the request with the latest responses?
Grahame Grieve (Dec 19 2016 at 19:23):
there's really only the examples you were looking at.
Grahame Grieve (Dec 19 2016 at 19:24):
and it's certainly possible - do we need to do anything in the spec to help? I can't think of anything?
Mat Coolidge (Dec 20 2016 at 12:25):
I would find it useful to see a detailed example of the POST calls with URL and body and the defined returns
Mat Coolidge (Dec 20 2016 at 12:26):
For example do all batch operations occur at root? Can you perform one on a given resource like a patient and pass the param into the batch operations?
Mat Coolidge (Dec 20 2016 at 12:28):
I would like to be able to perform it on a list that references patients and have the first patient GET take the resource ref then use the ref for the allergies, meds, ets
Mat Coolidge (Dec 20 2016 at 12:28):
etc
Mat Coolidge (Dec 20 2016 at 12:29):
it sounds like that might include one batch operation calling others, which we can do
Grahame Grieve (Dec 20 2016 at 12:34):
you post the batch to root, but the things with in it have their own path. The examples include both request and response
Joe Blue (Dec 27 2016 at 13:51):
I have implemented FHIR with protocol Buffers. It still exposes everything over a Restful JSON API also. Has anyone done this too . I am looking for collaborators and testers
Last updated: Apr 12 2022 at 19:14 UTC
