Stream: implementers
Topic: Diagnostic Order with multiple items to ProcedureRequest
Mritunjay Dubey (Apr 06 2017 at 04:06):
Hello people,
In DSTU2 we have few DiagnosticOrder with multiple items. For a test panel, we were populating all the test orders as multiple items of same diagnostic order. Now while converting we are getting issues since procedurerequest is for used for a single item.
I read about compound-requests(http://hl7.org/fhir/STU3/request.html#compound). I thought I can use Request.requisitionId because the definition says "by the same practitioner at the same time for the same subject" , which is the same scenario for a panel.
Here is what I think the conversion should be. Below is the structure of a diagnostic order with multiple items
DiagnosticOrder
Item A
code
event
status => created
Item B
code
event
status => created
I think it can be converted in below structure
ProcedureRequest A
code ?(Not sure what this should be)
ProcedureRequest B
requisition => A
code => Item A.code
status active
ProcedureRequest C
requisition => A
code => Item B.code
status active
In above structure ProcedureRequestA is a composite request, and ProcedureRequestB and ProcedureRequestC are the concrete which will refer to ProcedureRequestA as requisition. Here I want to validate my idea. is this the way this should be converted or there should be a different approach to it. Another question, since ProcedureRequest.code is a mandatory field what should that be ideally.
Sunanda Veeraganti (Apr 06 2017 at 09:28):
Procedure B and Procedure C are not clear. In ProcedureRequest B, code => Item A.code and in ProcedureRequest C, code => Item B.code. Does that mean Procedure B is also composite and Procedure C is concrete?
Mritunjay Dubey (Apr 06 2017 at 09:33):
No! Actully, what I meant there is one Composite PRequest "A" and there are two concerete PRequests "B" and "C" for each item. Both concrete PRequests will be referring to "A" as requisition.
Sunanda Veeraganti (Apr 06 2017 at 11:04):
ProcedureRequest.code is a codeable concept. For a Diagnostic Procedure the code is - 103693007 Diagnostic procedure
Mritunjay Dubey (Apr 06 2017 at 11:07):
Shouldn't that be procedurerequest.category i.e. what type of procedurerequest is this? procedurerequest.code should be specifying what is being ordered as in "Test Name"
Sunanda Veeraganti (Apr 06 2017 at 11:17):
Both Category and code are codeable concepts. yes you are correct. The Value set is defined here. http://hl7.org/fhir/STU3/valueset-procedure-code.html
Mritunjay Dubey (Apr 06 2017 at 11:27):
Yeah correct! This is an example binding, this can be totally different in my context.
Mritunjay Dubey (Apr 06 2017 at 11:30):
Sorry, I think we have deviated from the main question? My question was more about, is that the proper use of PRequest. requisition. If yes what should be code for the composite PRequest.
Sunanda Veeraganti (Apr 06 2017 at 12:01):
A new code should be defined for composite PRequest. Prequest code is not appropriate. solution.
Mritunjay Dubey (Apr 06 2017 at 12:03):
Okey I agree to that. Otherwise that I just wanted to know is this a proper use of PRequest. requisition ?
Yunwei Wang (Apr 06 2017 at 14:04):
@Mritunjay Dubey ProcedureRequest.requisition is an unique identifier. You don't need to create instance of a ProcedureRequest to hold that identifier. As long as all the requests have the same identifier, they are treated as in a composition. Here is the description from STU3: Requests are linked either by a "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.
And PrcoedureRequestB.code and ProcedureRequestC.code should be their own SNOMED CT procedure code.
Your example is kind of confusing.
Lloyd McKenzie (Apr 06 2017 at 14:48):
There's no need to introduce an addtional ProcedureRequest A. You just have one ProcedureRequest for each item and a common requisitionId on both. There's no need to introduce a composite order in most cases. The exception is if there are timing dependencies or conditionality dependencies for the child items - e.g. an order to do A or B, but not both. In that case, ProcedureRequestB and ProcedureRequestC would have a ProcedureRequest.intent of "option" and you'd have a RequestGroupA that pointed to both. The RequestGroupA would manage the relevant status, timing, etc. for all of its options.
Mritunjay Dubey (Apr 06 2017 at 16:07):
@Lloyd McKenzie @Yunwei Wang thanks! That was helpful.
Mritunjay Dubey (Apr 10 2017 at 06:56):
Hello guys, As we discussed above A diagnosticorder with multiple items will be converted to separate procedure requests. Right now we have just one value identifier and id field populated for whole diagnostic order. Now we need multiple identifier and id one each for every procedure request. is there a standard way to deal with this problem?
Mritunjay Dubey (Apr 10 2017 at 06:57):
The same problem is with entry.fullUrl since a single entry will be changed to multiple entries
Sunanda Veeraganti (Apr 10 2017 at 09:27):
@Mritunjay Dubey Will there be a problem using multiple identifiers in your scenario?
Mritunjay Dubey (Apr 10 2017 at 09:36):
Yeah! We just thought of going with multiple identifier which we will generate. I was just wondering if there is a standard rule/guideline by fhir.
Sunanda Veeraganti (Apr 10 2017 at 09:38):
If you are creating multiple procedure requests then it is better to have identifers for each request. It will be clean. I am also curious to see if any one proposes a better solution
Lloyd McKenzie (Apr 10 2017 at 14:10):
If you don't have identifiers for each order entry, just append ".1", ".2" or "-1" or "-2". There's no particular guidance because only you know what's going to be unique and reliable in your environment.
Mritunjay Dubey (Apr 10 2017 at 14:43):
yeah true! Even I thought of appending something, but just wanted to make sure that it is not wrong. Thanks
Mritunjay Dubey (Apr 19 2017 at 09:29):
A new question, The conversion scripts are adding an extension with url "http://hl7.org/fhir/diagnosticorder-r2-marker" while converting DiagnosticOrder to ProcedureRequest, but it says it is unknown. Am I missing anything here?
Grahame Grieve (Apr 19 2017 at 12:17):
that's so the mapping can round trip back to DiagnosticOrder, but it's not a formally defined extension
Mritunjay Dubey (Apr 19 2017 at 12:20):
ohh okey, it is just to identify that this ProcedureRequest is converted from DiagnosticOrder.
Grahame Grieve (Apr 19 2017 at 12:22):
yes
Last updated: Apr 12 2022 at 19:14 UTC
