Stream: implementers
Topic: Claim references?
Peter Bernhardt (Sep 02 2016 at 18:40):
Looking at definition of Claim i see quite a few properties defined in an unconvential way
Peter Bernhardt (Sep 02 2016 at 18:41):
See http://hl7-fhir.github.io/claim.html
Peter Bernhardt (Sep 02 2016 at 18:41):
properties like insurer[x], provider[x], organization[x], etc. can either be an Identifier or a ResourceReference.
Peter Bernhardt (Sep 02 2016 at 18:42):
why ? A ResourceReference can be an internal reference which could simply be a fully qualified identifier (system + value)
Peter Bernhardt (Sep 02 2016 at 18:42):
i'm concerned that this deviates from the pattern used everywhere else.
Peter Bernhardt (Sep 02 2016 at 18:49):
I suppose i may be pushing use of internal id here, but then why not just create a resource with one identifier? and reference that?
Peter Bernhardt (Sep 02 2016 at 18:56):
Same pattern in Coverage ... sigh
Grahame Grieve (Sep 02 2016 at 20:39):
yes you'll see that the FM group has simply disagreed with the overall architecture pattern, and acted accordingly
Grahame Grieve (Sep 02 2016 at 20:39):
this will be discussed at Baltimore
Paul Knapp (Sep 03 2016 at 07:08):
As currently defined a ResourceReference CANNOT be a be a fully qualified identifier (system + value) and it must be referenceable. So if what you have is the business identifer (or you don't allow the resources to be referenced) you must either create a second resource or a contained resource and use internal references to those - the contained resource being more efficient in the Financial space) and shown in existing financial examples. The choice of a resource reference or identifier is even more efficient than a contained resource in these cases and we are proposing a datatype change so that we drop the choice then all resources will follow the same approach.
Paul Knapp (Sep 03 2016 at 07:11):
@Grahame Grieve: FM doesn't diagree with the overall approach, we use it where it works and propose solutions where it doesn't meet the business need. What we don't do is force the business requirements to fit the solution architecture.
Come meet with FM on Wednesday in Baltimore to discuss.
Grahame Grieve (Sep 03 2016 at 21:55):
you do disagree with the overall approach, in that the overall approach is to use contained resources, which we do for good reason. As Peter references. But we will discuss
Paul Knapp (Sep 04 2016 at 05:14):
The problem with contained resources, or creating another resource, which only contains the business identifier is that inorder for that to be true we would need to require that there are no required fields other than perhaps the business identifier - which currently we don't. The reason for that restriction is that you would have the identifier but you may not know any of the currently required elements. - See the unsolicited attachment example on Communication - which FM created and which uses contained resources - it shows that we'd need to move the bar on attribute requirements on resources.
Paul Knapp (Sep 04 2016 at 05:20):
We had used contained resources and we were told that we should not - that we should create a separate resource - so we sought a better solution. We have examples using contained resources (and none where we have a separate resource) and we have proposed also using the business identifier as have other resources not just those from FM. The difference with the FM proposed approach is that we have made it a choice using the FHIR choice mechanism, the other resources have used both attributes. The datatype proposal I'm submitting for discussion would provide for both of these without the bloat of additional semi-redundant attributes.
Grahame Grieve (Sep 04 2016 at 10:18):
so now you are defending why you are different - and we can (and will) talk about this in Baltimore.
Paul Knapp (Sep 04 2016 at 10:49):
Yes, we prefer there be a rationale. We support the approach when it works.
Lloyd McKenzie (Sep 05 2016 at 02:22):
I think it makes sense to allow the Reference data type to support both direct and logical references. Logical references are a reality in a number of architectures and it seems reasonable to support that in core.
Paul Knapp (Sep 05 2016 at 06:52):
Can we discuss this Tuesday Q1 with M&M, FHIR-I, ITS?
Paul Knapp (Sep 05 2016 at 06:54):
@Lloyd McKenzie I agree, and I'd prefer that we add an identifier attribute to capture the logical rather than mix both in the reference attribute of the Reference data type.
Lloyd McKenzie (Sep 05 2016 at 19:13):
Yes. My expectation is that the Reference data type would end up with three properties - reference, identifier and display.
Grahame Grieve (Sep 05 2016 at 20:39):
we have discussed and rejected this option before.
Lloyd McKenzie (Sep 06 2016 at 13:47):
@Grahame Grieve My understanding was we were planning to discuss it in Baltimore. I don't recall it being discussed in detail previously, nor the reasons for its rejection (though I do recall discussions about whether it should be core or a standard extension)
Lloyd McKenzie (Sep 06 2016 at 13:49):
In a RESTful space, external reference by URI make sense. But in a messaging or other non-RESTful space, external references by URI don't make much sense and aren't a capability many of the existing systems would have.
Grahame Grieve (Sep 06 2016 at 20:06):
it was a long time ago, but we did
Lloyd McKenzie (Sep 06 2016 at 21:25):
@Grahame Grieve I'm just clarifying that you're still on board with discussing and potentially revisiting that discussion in Baltimore.
Grahame Grieve (Sep 06 2016 at 23:12):
open to discussing it. But there's a lot of ramifications to consider
Elliot Silver (Sep 09 2016 at 20:57):
I think we had a similar case come up with DiagnosticReport, in that the report wants to note that it is related to a particular imaging study UID (DICOM study instance identifier), but creating an ImagingStudy resource devoid of any content except the identifier seems a little heavy. It also doesn't handle the case where the ImagingStudy resource isn't supported by the EMR (because it figures the PACS should handle those resources) or the PACS (because it doesn't have FHIR support), but we still want to include the study UID in the report.
Should DiagnosticReport.imagingStudy be changed to imagingStudy[x], where x=Reference(ImagingStudy) or Identifier (or whatever the proper way to write that is)? Is @Lloyd McKenzie's suggestion of adding identifier to the Reference type the right way? I'm not sure.
Paul Knapp (Sep 10 2016 at 18:43):
imagingStudy[x] ?..? Reference(ImagingStudy) | Identifier
Agree creating an ImagingStudy instacne just to contain the identifier is heavy, it also isn't valid - it would need to contain the identifier, patient, numberOfSeries and numberOfInstances to be valid.
In FM we had proposed providing a choice as above to deal with the requirement for business identifier rather than the approach taken by other committees of using two attributes, one for the reference and one for the identifier.
We are now proposing that 'identifier 0..1 Identifier' be added to the Reference data type. Then all of the different solutions could harmonize on that. It would mean a receiver of a reference with just an identifier could complete the reference should they know it.
Grahame Grieve (Sep 12 2016 at 18:11):
I'm suspicious of this. It seems to be making life easy for authors at the cost of making it very difficult for the readers
Lloyd McKenzie (Sep 12 2016 at 20:06):
If all the author has is an identifier - and they cannot/will not stand up a FHIR server to host the resource at a URL, then that's the reality. The data that's going to be exchanged is the data that's going to be exchanged. The only question is whether it's done using wonky mechanisms like contained resources or an extension on Reference or whether it's recognized as part of core. In a fully RESTful world, it's unnecessary and possibly inappropriate. But much of the world isn't (and isn't going to be - at least for a long time) RESTful.
Paul Knapp (Sep 14 2016 at 21:50):
And we don't want people to put content into reference.reference which aren't valid references.
Last updated: Apr 12 2022 at 19:14 UTC
