Cannot parse R5 StructureDefinition-integer64.json

[GinoCanessa]

Describe the bug
The default parser errors when parsing StructureDefinition-integer64.json from the core R5 package (version 5.0.0). Specifically, it is trying to parse snapshot.element[3].minValueInteger64 as a Date instead of an Integer64.

The exception it throws is listed below (in screenshots).

To Reproduce
Steps to reproduce the behavior:

Assuming the definition is present in TestData:

string path = System.IO.Path.Combine(System.IO.Directory.GetCurrentDirectory(), "TestData", "StructureDefinition-integer64.json");
string json = await System.IO.File.ReadAllTextAsync(path);
FhirJsonPocoDeserializer parser = new(new FhirJsonPocoDeserializerSettings()
{
  DisableBase64Decoding = false,
  Validator = null,
});
Resource parsed = parser.DeserializeResource(json);

Expected behavior
Successful parsing of the resource.

Screenshots

Hl7.Fhir.Serialization.DeserializationFailedException: 'One or more errors occurred. (Json string '-9223372036854775808' cannot be parsed as a Date, because it should be a Json number. At StructureDefinition.snapshot.element[3].minValue, line 191, position 52) (Json string '9223372036854775807' cannot be parsed as a Date, because it should be a Json number. At StructureDefinition.snapshot.element[3].maxValue, line 192, position 51) (Json string '-9223372036854775808' cannot be parsed as a Date, because it should be a Json number. At StructureDefinition.differential.element[1].minValue, line 234, position 52) (Json string '9223372036854775807' cannot be parsed as a Date, because it should be a Json number. At StructureDefinition.differential.element[1].maxValue, line 235, position 51)'

(emphasis mine)

Version used:

• FHIR Version: R5
• Version: 5.5.1 and develop branch current as of Feb 6 (commit 5113eef).

Additional context
The issue appears to be in the deserializePropertyValueInto function in ...\src\Hl7.Fhir.Base\Serialization\BaseFhirJsonPocoDeserializer.cs. Specifically, the line that sets the fhirType that will be used in the next deserialize call in the nest when deserializing elements that are choice types with primitives. I tested both of the following changes and they both correct the issue. However, there are a lot of failing tests on my system (I believe unrelated to the current issue) and could not tell the impact of the changes.

Option 1:
Change:

var fhirType = propertyMapping.FhirType.FirstOrDefault();

to

var fhirType = propertyValueMapping.NativeType;

Since we already know that the property mapping is to a primitive type, simply use the type from that mapping. I am not sure I have all of the context correct to apply as a one-liner, so I also tested the following.

Option 2:
Change (same line):

var fhirType = propertyMapping.FhirType.FirstOrDefault();

to

Type? fhirType;

if (propertyMapping.FhirType.Contains(propertyValueMapping.NativeType))
{
    fhirType = propertyValueMapping.NativeType;
}
else
{
    fhirType = propertyMapping.FhirType.FirstOrDefault();
}

This option has a little performance hit but specifically checks to see if the property mapping has the desired type in it. Again, I am not sure if this check is necessary or not at this point, but figured it was easier if I provided both.

[GinoCanessa]

Note that I am happy to submit as a PR if that is easier. Please just let me know if there is a preference for Option 1 or 2. Cheers!

[mmsmits]

First one breaks some unit tests locally here, second one doesn't, so second one it is :)
A PR would be great!

[GinoCanessa]

Perfect, PR #2702 has that change (reformatted). Thanks!