Stream: dotnet
Topic: Possible parse bug
Ken Miller (Jul 28 2021 at 05:01):
I am using the HL7.FHIR.DSTU2 (1.9.0) package against an AllScripts sandbox FHIR server. When I make the simple request:
FhirClient.SearchAsync("Patient", new List<string> { $"_id={id}" }, null, null,null,null);
I get the following exception thrown:
FormatException: Type checking the data: Encountered unknown element 'p' at location 'Bundle.entry[0].resource[0].text[0].p[0]' while parsing
When I run this query under Postman, the following text element is returned (fake data, of course)
"text": {
"status": "generated",
"div": "<p><tr> <td>Name</td> <td>Amanda <b>Sanchez</b> ("Amanda")</td> </tr><tr> <td>Address</td> <td>543 Cedar Crest Dr Forest Lake Mn 55025</td> </tr><tr> <td>Contacts</td> <td>Home: (999) 148-2703. Work: </td> </tr><tr> <td>Id:40253</td> <td>MRN: 210616075554183 </td> </tr></p>"
}
I don't see a p element that the exception message is referring to. Is the parser somehow being fooled by the HTML paragraph element inside "div"?
Ken Miller (Jul 28 2021 at 05:22):
A bit more info: I found I could avoid the exception being thrown with more permissive parser settings. However, the Div in the Model is parsed out to null in this case.
Brian Postlethwaite (Jul 28 2021 at 06:20):
This is because that isn't valid FHIR content, the narrative must be a <div ...> at the outside.
https://hl7.org/fhir/narrative.html
Brian Postlethwaite (Jul 28 2021 at 06:21):
This is due to the narrative being XHTML, and not re-encoded within XML, and is just regular XML tags in the document using the XML namespace rather than fhir.
Ken Miller (Jul 28 2021 at 13:39):
Thanks. So I need to contact AllScripts and file a bug report? Sigh, with AllScripts history they'll do nothing for years, and blame the tool for not being more permissive.
Ewout Kramer (Jul 28 2021 at 14:47):
Ken, let us know how this progresses. Maybe they have an upgraded endpoint (on STU3?) that is more conformant?
Ken Miller (Jul 28 2021 at 15:35):
Will do. Unfortunately, they still only support DSTU2. They've indicated on their FHIR developer's forum that supporting later FHIR versions is in their plans with no timeframe, but this was from 2019 and crickets since. They don't even support the Encounter resource in DSTU2, which is a showstopper for many kinds of applications. Similarly, they announced in 2019 that support was planned, and then nothing. Quality FHIR support is clearly not a priority for them, which is very unfortunate given they are one of the few major EHR providers around. I wish HL7 would define a minimum level of compliance to claim FHIR compatibility, and would more aggressively sunset older versions to pressure vendors to keep up with newer version.
Ewout Kramer (Jul 29 2021 at 07:38):
Well, the "DSTU" stands for "Draft Standard for Trial Use", so clearly a drafty, temporary thing. But that's just not how these things work unfortunately, and even HL7 is in no position to enforce anyone to drop DSTU2....
Ewout Kramer (Jul 29 2021 at 07:39):
(but, yes, I agree of course, we dropped support for DSTU2 for the .NET SDK a while ago since you simply cannot keep supporting everything)
Ken Miller (Jul 29 2021 at 21:13):
Yes, I assume HL7 leaving v2 in DSTU purgatory was meant to be a signal to vendors that they needed to quickly move on to newer pastures, but it's one many didn't heed. After spending fortunes implementing doomed C-CDA and then more investment in FHIR to correct for this mistake, the appetite and budget weren't there for FHIR support to be a continuous development project. As a frequent HL7 critic, I agree HL7 should not have the power to force anything, but old versions should be formally sunsetted after a reasonable period of time so vendors can't legitimately claim FHIR support if that's their only level.
I won't criticize the decision to drop support for DSTU2 in newer SDK versions, since I'm sure it's made SDK development far more efficient and enjoyable. However, it presents practical difficulties as so many large vendors still only support DSTU2. It also makes applications designed to access a range of FHIR servers encompassing DSTU2 and R4 incredibly tedious to develop. To keep things simple, I'm just writing dedicated applications for particular versions (I'm aware of the extern alias method, but I found it led to extremely messy code). Thanks for all the great work on the SDK!
Last updated: Apr 12 2022 at 19:14 UTC
