Stream: implementers
Topic: ordering vs authorizing provider
Craig Newman (Mar 18 2019 at 19:05):
Within ServiceRequest, is there a typical pattern for documenting the different individuals involved in ordering a test or procedure? One of the more complicated scenarios is where a practitioner without full ordering credentials may "order" a test that then is verified/authorized by a different provider with full ordering credentials. On top of that, there may be some insurance "pre-auth" that has to happen. How are these different roles captured in ServiceRequest? Which one goes in ServiceRequest.requester? Are the other roles captured in a Provenance record (role of verifier?) Or does .requester change as the intent goes from "plan" to "order"? Or does a Task with .type of "approve" capture the authorization for the order?
Lloyd McKenzie (Mar 18 2019 at 19:43):
Typically the fine-grained responsibilities are captured using Provenance (data enterer, initial proposer, etc.) and only the individual who 'signs' is captured on the resource. You could also reflect the order as being done in response to a 'proposal' by the non-credentialed individual. The Pre-auth would be represented using Claim.
Craig Newman (Mar 21 2019 at 14:11):
If a ServiceRequest moves from a proposal from an non-credentialed person to an order approved by a credentialed person, would that typically just be an update to ServiceRequest.intent in a new version of the existing resource, or would a new ServiceRequest resource be created with a .intent of "order" and a reference back to the proposal resource in .basedOn?
Lloyd McKenzie (Mar 21 2019 at 16:07):
New ServiceRequest with a basedOn link. 'intent' is considered immutable
Eric Haas (Mar 21 2019 at 20:15):
New ServiceRequest with a basedOn link. 'intent' is considered immutable
Really? if that is true one would think it'd be documented somewheres.
Eric Haas (Mar 21 2019 at 20:17):
I think its just like any other element,... dealer's choice .... you can create new versions or new resources. Are we talking about the base spefication here?
Jens Villadsen (Mar 21 2019 at 20:20):
@Lloyd McKenzie who considers it immutable besides you? I can't see how the spec does
Lloyd McKenzie (Mar 21 2019 at 21:17):
http://build.fhir.org/request-definitions.html#Request.intent
Lloyd McKenzie (Mar 21 2019 at 21:17):
Even the 'short name' mentions that it's immutable in the pattern
Lloyd McKenzie (Mar 21 2019 at 21:18):
If there are places where the relevant usage notes haven't propagated into specific request resources from the pattern, please submit a change request.
Jens Villadsen (Mar 21 2019 at 21:40):
Got it, thx. It says 'expected' - not required or mandated. That is sort soft for such a characterisation
Lloyd McKenzie (Mar 21 2019 at 21:56):
There are reasons for exceptions, for example clarifying that an 'order' is in fact an 'original-order' once that fact is confirmed.
Eric Haas (Mar 22 2019 at 07:09):
Seems like a very important implementation detail To be buried in the comment field for the pattern element. How many folks are going actually find and read that. .
Eric Haas (Mar 22 2019 at 07:14):
How many other immutabke elements are there?
Lloyd McKenzie (Mar 22 2019 at 14:24):
It was surfaced in the short description too. I'm not aware of others.
Last updated: Apr 12 2022 at 19:14 UTC
