firely-net-sdk
firely-net-sdk copied to clipboard
FirelyTeam
Unable to parse JSON from Epic App Orchard FHIR server because of 64 character ID limit.
Is your feature request related to a problem? Please describe. When using Hl7.Fhir with Epic App Orchard we are getting FhirJsonParser errors because some of the FHIR IDs from Epic are longer than 64 characters. it appears to happen for multiple resource types (Patient, Conditions, and Observations).
Describe the solution you'd like We understand that the validation is generated from the FHIR specification and that specification says IDs are limited to 64 characters but we would like a way to override this behavior.
Describe alternatives you've considered We have modified the source code to allow IDs up to 70 characters and the solution is working for our Epic App Orchard clients but we are concerned about maintaining our changes as new versions of the package are released.
I have reached out to Epic to confirm this and ask them what's going on. - they'll run into trouble with other clients too.
For now, there's nothing you can do - as you've noted it's simply illegal what they are doing, so I never thought about making that variable in the parser. I have a solution in the making for the next major .NET SDK release, but that's still a while off.
The gentle people at Epic have responded: here's the long running discussion on this: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Epic.20has.20IDs.20that.20are.20more.20than.2064.20characters
ultimately, yes currently our algorithm that generates FHIR ids that can be mapped to distinct resources/odb concepts can generate ids that are longer than 64 characters. We're actively looking at redesigning how this mapping works, to try to avoid this for many, but not all resources, but the fix is only under design now, so it will be probably 18 months +/- before it's widely deployed.
It seems then, that there is no other work around for the coming 2 years than disabling this check.
Hmmm I agree, that we have to disable this check then. Although we are making this more flexible in the 4.0 release anyway right? But @jonfleming and other might need this asap. So maybe we should consider this to be released with 3.7.
I think it's a bad thing that we deviate from the standard. On the other hand, users must be able to parse data. In version 4.0 we are a little more flexible and we can handle this better. For version 3.x we could disable this check, but I would prefer to make it configurable
+1 for making it configurable, and that the check is enabled by default
And then we should call it "EpicOrchardCompatibilityMode" I guess, so we are nicely explicit and can also add additional issues with Epic if we would encounter them.
Well definitely not 3.6 because it is already released :) We're about to release 3.7, so if it's really easy to implement I could still add it to 3.7
@jonfleming can you give us an example of a resource where the parsing fails?
I've create the following test and that succeeds in STU3 and R4:
[Fact]
public void JsonIds()
{
var settings = new ParserSettings
{
PermissiveParsing = false
};
var parser = new FhirJsonParser(settings);
var input = $"{{\"resourceType\": \"Patient\",\"id\": \"{new string('x', 300)}\" }}";
var patient = parser.Parse<Patient>(input);
patient.Id.Length.Should().Be(300);
}
In this case the id of the patient has a length of 300.
The new FHIR client can handle all of this neatly now: https://docs.fire.ly/projects/Firely-NET-SDK/en/latest/client/setup.html#selecting-a-serializer