Stream: implementers
Topic: R4 ServiceRequest
Michele Mottini (Jun 17 2019 at 15:42):
...it replaces STU3 ProcedureRequest _and_ ReferralRequest, correct?
Drew Torres (Jun 17 2019 at 15:43):
That is how I understand it.
Michele Mottini (Jun 17 2019 at 15:46):
Thanks Drew (we are trying to finish R4 support quickly so we can onboard a new customer on that instead of DSTU2 or STU3)
Michele Mottini (Jun 18 2019 at 21:46):
Follow up: is there a way to tell which ServiceRequest are referrals and which are orders? intent seems to be that, but has almost the exact same values of STU3 ProcedureRequest and ReferralRequest
Eric Haas (Jun 18 2019 at 22:09):
I forget the details, but we talked about it at the time, but no action. But basically what is the difference intrinsically, you identify a performer and you have a code so implicit in that is an order for referral. could use category to define a code for these are referals?
Eric Haas (Jun 18 2019 at 22:09):
no trackers on this even though we brought up when merged.
Michele Mottini (Jun 18 2019 at 22:16):
Thanks Eric. from the examples codes category seems more the class of services that are been ordered - and we are mapping that already to properties in our data model
Michele Mottini (Jun 18 2019 at 22:16):
The issue I have is that in our data model referrals and order are separate, so when the server receive a POSTed ServiceRequest it has to decide where to put the data
Michele Mottini (Jun 18 2019 at 22:17):
I can use always Order or maybe add a custom extension to preserve round-trips
Eric Haas (Jun 19 2019 at 00:53):
Sr.category is 0..* and the binding is example. I think you could create your own orthogonal categorization of request types.
Last updated: Apr 12 2022 at 19:14 UTC
