-
Notifications
You must be signed in to change notification settings - Fork 579
CapabilityStatement returned by the /metadata route does not conform to the FHIR standard #5394
Description
Describe the bug
Our project uses the Firely C# libraries for FHIR parsing and manipulation (https://github.com/FirelyTeam/firely-net-sdk). Following a recent major version bump to 6.0.2, the parsing was made stricter by default and when parsing the CapabilityStatement returned from the FHIR server we have been getting this error:
Hl7.Fhir.Serialization.DeserializationFailedException: One or more errors occurred. (Element 'CapabilityStatement.rest[0].resource[116].interaction' with minimum cardinality 1 must be present. At CapabilityStatement.rest[0].resource[116].interaction, line 1, position 774573.)
I believe the resource it is complaining about is Parameters, which is a bit of a funny resource. It is explicitly excluded from populating interactions in the code here: https://github.com/microsoft/fhir-server/blob/main/src/Microsoft.Health.Fhir.Core/Features/Conformance/CapabilityStatementBuilder.cs#L303. I'm not sure whether Parameters should be returned in the CapabilityStatement at all, or if it should but with some interactions. Would we expect clients look at the CapabilityStatement to see if they can use Parameters, or would they just use them?
FHIR Version?
Stu3
Data provider?
SQL Server
To Reproduce
Steps to reproduce the behavior:
- Query the /metadata route
- Manually check the output for the
Parametersresource insideCapabilityStatement.restagainst the FHIR specification (https://www.hl7.org/fhir/STU3/capabilitystatement.html), or try to parse using a recent version (6 series, we are using 6.0.2) of the Firely C# FHIR libraries.
Expected behavior
The /metadata endpoint should return a CapabilityStatement that conforms to the FHIR standard, although as noted above I'm not sure what the actual behaviour should be.
Actual behavior
The /metadata endpoint returns a CapabilityStatement that deviates from the FHIR standard.