Stream: implementers
Topic: Procedure Request Type of request
Mritunjay Dubey (Mar 30 2017 at 11:36):
Hey Guys, Since Diagnostic Order is merged with ProcedureRequest we are finding it difficult, how we will differentiate between two different type of procedure request.
For Example, if I have a LabOrder and a RadiologyOrder how should I figure out which one is what type of order? I looked through the resource but couldn't get a similar element/field for procedure request. Has anyone faced this issue before ?
Michel Rutten (Mar 30 2017 at 12:05):
What about ProcedureRequest.code?
http://hl7.org/fhir/procedurerequest-definitions.html#ProcedureRequest.code
Mritunjay Dubey (Mar 30 2017 at 12:16):
I feel this code part will tell me what I am ordering/requesting, but I want more like the order/request what I have placed what type of order is that.
For example A request with code White blood cell count is a LAB Order and A request with a code Skeletal X-ray of ankle and foot is a Procedure Order or Radiology Order (not sure). I was wondering , is there a way to specify that whether it is a radiology order or lab order.
Michel Rutten (Mar 30 2017 at 12:25):
ProcedureRequest.category may be better suitable. Note that the element has an example valueset binding, so a derived profile is allowed to constrain the binding to a concrete valueset.
Mritunjay Dubey (Mar 30 2017 at 12:43):
yeah, I think that will fulfil our requirements. Thank you!
Michel Rutten (Mar 30 2017 at 12:44):
np
Eric Haas (Mar 30 2017 at 16:05):
Yes the intent of category is to do what you are asking.
Grahame Grieve (Apr 03 2017 at 02:26):
I think OO should endevour to get a similar strength binding as for Observation.category - otherwise this will be harder to implement
Mritunjay Dubey (Apr 03 2017 at 03:51):
Hey @Grahame Grieve Dumb question, by OO whom are you refferning ?
Alexander Henket (Apr 03 2017 at 03:52):
HL7 Work Group Orders & Observations (http://wiki.hl7.org/index.php?title=Orders_%26_Observations_WG)
Mritunjay Dubey (Apr 03 2017 at 03:52):
ohh okey! thanks
Eric Haas (Apr 03 2017 at 16:25):
@Grahame Grieve Observation category cardinality is 0.* and Binding strength is preferred. The Procedure.category value set is used in other places such as Procedure. Are you suggesting it be bumped to preferred or that we should look at creating a set of higher level FHIR codes like we did with Observation.category to avoid the SNOMED restrictions on use and allow for universal adoption? -
Lloyd McKenzie (Apr 03 2017 at 17:04):
It'd be nice if both categories were Extensible - so you could rely on at least certain categories being consistently populated by all systems
Eric Haas (Oct 24 2017 at 20:23):
Reopening this stream since ServiceRequest nee Procedure/Referral/DiagnosticRequest is missing a binding to category. GF#13868
First re Lloyd's wish: "It'd be nice if both categories were Extensible - so you could rely on at least certain categories being consistently populated by all systems" ain't gonna happen unless:
- cardinality were 0..1
- binding to a Universal set ( e.g. FHIR codes)
- get agreement on a code set
I would not hold my breath...
Eric Haas (Oct 24 2017 at 20:28):
back to ServiceCategory request:
Base on OO on FHIR discussion these type of concepts are more in line with the definition of .category
- Laboratory
- Imaging
- Education
- Surgery
...but we were not sure these are usable categories
... and this does not differentiate
- Diagnostic
- Procedure
- Referral
Do we need to differentiate these three things within this resource - We thought we did when we merged them but no clear path for it..
Suggestions?
Michelle (Moseman) Miller (Oct 26 2017 at 13:09):
Do we need to differentiate these three things within this resource - We thought we did when we merged them
We merged these 3 resources into one ServiceRequest because implementers weren't categorizing consistently (i.e. no universal, consistent definition of the boundaries between procedure, referral, and diagnostic).
How does category align (or not) with the order catalog? (I'm out of touch with recent order catalog work....) For example, it would be straight forward to derive category from the order catalog type, but that implies differences in how each system might build their catalog (determine category).
Eric Haas (Oct 26 2017 at 16:34):
@Jose Costa Teixeira can you answer the Catalog category part - I don't see any bindings in catalog entry
Jose Costa Teixeira (Oct 26 2017 at 16:37):
@Michelle (Moseman) Miller : I'd say bingo! :
Jose Costa Teixeira (Oct 26 2017 at 16:41):
"We merged these 3 resources into one ServiceRequest because implementers weren't categorizing consistently (i.e. no universal, consistent definition of the boundaries between procedure, referral, and diagnostic)."
Expectable?, i'd say.
Jose Costa Teixeira (Oct 26 2017 at 16:42):
" it would be straight forward to derive category from the order catalog type, but that implies differences in how each system might build their catalog (determine category)." Yep
Jose Costa Teixeira (Oct 26 2017 at 16:42):
ServiceRequest.Category aligns with Catalog as follows:
Jose Costa Teixeira (Oct 26 2017 at 16:45):
From a catalog perspective, the serviceDefinition contains characteristics that are context-independent.
Catalog can add any characteristics that are context-sensitive.
I can't think of any example cc bindings.
Jose Costa Teixeira (Oct 26 2017 at 16:46):
take LabOrder and RadiologyOrder: these seem well context-independent
Last updated: Apr 12 2022 at 19:14 UTC
