Stream: implementers
Topic: Mixing DSTU2 and STU3
John Moehrke (Jul 21 2016 at 20:02):
What are the anticipated problems if someone wanted to use a STU3 resource definition in a DSTU2 server?
Grahame Grieve (Jul 21 2016 at 20:09):
well, there's lots of reasons why that can't work, but what are you trying to do?
John Moehrke (Jul 21 2016 at 20:13):
IHE -- Where MHD is based on DSTU2; but where Radiology doesn't want to waste time at DSTU2 (ImagingObjectSelection) but rather go direct to STU3 (ImagingManifest).... One might force the DSTU2 rules upon it, and it then looks like a "Custom Resource"... :-)
John Moehrke (Jul 21 2016 at 20:15):
so, for majority of the client-server; it would be DSTU2 -- Patient, Provider, DocumentReference, DocumentManifest, AuditEvent, Provenance, Practitioner, Organization, Location, --- just one object would be served up different ImagingManifest.
Grahame Grieve (Jul 21 2016 at 20:57):
carumba. that is really bad idea.
Robert Horn (Jul 21 2016 at 21:29):
So what will go wrong? It's much like adding a custom resource (the DSTU3 thing) to an otherwise DSTU2 collection of resources.
Grahame Grieve (Jul 21 2016 at 21:41):
- we have no practical experience with custom resources and how they might actually work (e.g. reference implementations...)
- we haven't even be able to get consensus about a policy at all, after trying for months
- it's not like that if you think you're going to use the same name. That would just be straight non-conformance
- technically, the R3 dpends on the rest of ST3, but I suppose none of that is relevant. we hope
John Moehrke (Jul 21 2016 at 21:45):
so this is why we are asking the Implementer community for their guess on what the problems will be. I don't expect that this is already known. I don't expect that it will be easy. I just want to get guesses at how bad it will be.
John Moehrke (Jul 21 2016 at 21:45):
So the MIME-TYPE change between DSTU2 vs STU3 is easy... the transport will be DSTU2.
John Moehrke (Jul 21 2016 at 21:46):
We can just forbid the ImagingManifest from referencing anything. We really don't need the patient identity it is already known by the session context. (well, we need to put something there as it is 1..1).
Grahame Grieve (Jul 21 2016 at 22:04):
I don't see what referencing has to do with it
John Moehrke (Jul 21 2016 at 22:14):
okay. then I will not worry about references.
John Moehrke (Jul 21 2016 at 22:14):
what should I worry about?
James Agnew (Jul 22 2016 at 16:12):
There will be zero off the shelf tooling support for using DSTU3 resources with DSTU2 processing rules. That alone would make this idea a non-starter IMO.
John Moehrke (Jul 22 2016 at 16:28):
James, thanks. Good point. This is why I am trying to cast the ImagingManafest more as a custom resource being used in a DSTU2 environment. So Imaging Manifest would need to be hand coded.
Anand Mohan Tumuluri (Jul 22 2016 at 17:33):
We were almost about to do something similar; use CareTeam resource definition from STU3 into our DSTU2 based server. But I understand the associated problems w.r.t toolkit support.
Grahame Grieve (Jul 22 2016 at 20:21):
you should worry about
- policy approval for custom resources
- tooling support for custom resources
- social approval for custom resources
Grahame Grieve (Jul 22 2016 at 20:21):
why not just use STU3?
Last updated: Apr 12 2022 at 19:14 UTC
