Stream: fmg
Topic: QA - GF#12919 - Approved
Lloyd McKenzie (Mar 06 2017 at 05:12):
GF#12919 Issues discovered during QA that X.payee.resourceType which appears in Claim and ExplanationOfBenefit is a reserved work in the JSON serialization. Unpon review it was noted the the binding strength is different in the two uses (Example and Required). This element contains the name of the type of resource in refered to in the adjacent element in lower case. Given that additional elements may be added in the future it would be best to change the element in both cases to X.payee.resource code (extensible). Examples may also need to be updated to support these changes.
Lloyd McKenzie (Mar 06 2017 at 05:12):
+1
Grahame Grieve (Mar 06 2017 at 05:14):
+1
John Moehrke (Mar 06 2017 at 13:12):
+1
Brian Postlethwaite (Mar 07 2017 at 20:21):
+1 (although this is a more generic problem that we should revisit. anywhere you use the Identifier in the resourcereference type its used to indicate what type of thing you are referencing - particularly if there can be more than 1 type)
Paul Knapp (Mar 08 2017 at 04:51):
+1
Lloyd McKenzie (Mar 08 2017 at 05:13):
Approved
Paul Knapp (Mar 08 2017 at 05:17):
Also agree with Brian, I think there should be an element ( 0..1 code (list of resource names)) added to the Resource data type.
Paul Knapp (Mar 08 2017 at 05:25):
Need to do a friendly amendment - can't make the element a code with 'extensible' as codes MUST be 'required', therefore amend to coding rather than code.
David Hay (Mar 08 2017 at 05:41):
assume name is to be X.payee.resource with a dt of code?
Grahame Grieve (Mar 08 2017 at 20:51):
why is it extensible?
Brian Postlethwaite (Mar 08 2017 at 21:16):
I was wondering why it should be extensible also, has to be a fhir resource type)
Hans Buitendijk (Mar 08 2017 at 21:19):
+1
Paul Knapp (Mar 09 2017 at 06:43):
The code, name of the type of resource, should be extensible as there may be new resources created in the future which contain payee demographics. Or do we think there will be no more resources?
Paul Knapp (Mar 09 2017 at 08:44):
But now I see another issue: the party element is a choice of 4 resource types - so that list is not logically extensible. So, should I change that to Reference(All) to accommodate future resource types?
Grahame Grieve (Mar 09 2017 at 10:31):
I don't understand wanting to refer to future resource types
Grahame Grieve (Mar 09 2017 at 10:32):
in a future version, you will refer to future types
Brian Postlethwaite (Mar 09 2017 at 10:43):
Thats what i thought too.
Lloyd McKenzie (Mar 09 2017 at 14:30):
Unless a relationship has minOccurs=1, you can always use extensions to refer to future resource types. (And you can actually use dataAbsentReason or similar extensions to deal with minOccurs=1 elements, though you'll likely break systems doing that.)
Last updated: Apr 12 2022 at 19:14 UTC
