Stream: dotnet
Topic: Data Member Ignored for serializing
Lars Ewert (Feb 11 2022 at 08:57):
Hi all,
Im using in the Backend HL7.R4 SDK and saw, that some properties from HumanName wont get serialized, because they got the [IgnoreDataMember] Attribute, but I dont know why to be honest...
Since these are the official propertyNames from HL7:
image.png
My library in the Frontend @fhir/types uses the official property names and cant find the related Elements, because the Backend doesnt send them.
What is mapped and can be seen in the Frontend is this here :
image.png
Atleast i have the data in my Frontend, but not the way it should be provided from the official documentation and also the Interface HumanName from @fhir/types in the Frontend doesnt provide the properties with these Names.
Do i have to write my own interfaces for that, or am i missing somethign here?
Mirjam Baltus (Feb 11 2022 at 09:53):
For each of the fields in a resource or datatype structure that takes a primitive value (string, boolean, code, etc.) the model has two properties: one that has the regular fieldname and uses the native .Net datatype, another with 'Element' appended to the fieldname that uses the FHIR datatype. See https://docs.fire.ly/projects/Firely-NET-SDK/model/datatypes.html#primitive-data-types. So for the HumanName in your example, you will be able to find a 'Use' property that takes a value from a .Net enum and also a 'UseElement' property that takes a value of type Code - the FHIR equivalent.
In your serialized data, you would not want to see both properties, so one needs to have the [IgnoreDataMember] attribute. The .Net equivalent is ignored, since that one does not have a notion of extensions. If you use the FhirJsonSerializer, your data will be serialized correctly and you will see just the official property name in your FHIR output. See https://docs.fire.ly/projects/Firely-NET-SDK/parsing/poco-serialization.html#serialization-with-pocos.
Incoming data can be correctly parsed into the model with the FhirJsonParser: https://docs.fire.ly/projects/Firely-NET-SDK/parsing/poco-parsing.html#parsing-with-pocos.
Lars Ewert (Feb 11 2022 at 10:29):
Hi Mirjam,
Thank you for that explanation. I use a FhirClient, which collects the data form the Fhir Server and automatically parses them into a JSON. Is there a way, to use the FhirJsonParser to achieve this mapping directly when the response from the request arrives? So far the FhirClientSettings dont provide any properties for that.
Mirjam Baltus (Feb 11 2022 at 10:41):
If you use the FhirClient to retrieve data from a FHIR server, the client will already parse it into a resource POCO, so there should not be a need to use the FhirJsonParser. After the client request you will have your POCO, and can manipulate the data or serialize it, or anything else you want to do.
Lars Ewert (Feb 11 2022 at 11:01):
I´ve tested it out and as you said the result is the same...
But i think, my problem will stay the same, because when i try to send the data to my Frontend, the Elements wont get parsed, because the Object is still a HumanName and it uses the Attributes from the SDK when sending out.
Looks like, i have to serialize it to a string and not as Object "HumanName" to my Frontend and then parse the Information in the Frontend to HumanName, which is a bit uncomfortable, but will do the Job.
Writing duplicates of the HumanName in .NET just to remove the Attribute doesnt seem to be a common practice i think :D
Mirjam Baltus (Feb 11 2022 at 11:15):
Normally communicating FHIR data is done by communicating the XML or JSON representation of the data, not by using objects. The SDK is implemented for that normal way. I think that's why you're running into a wall here, and unfortunately will have to do some extra work if you want to continue using the objects. :)
Is it not possible to use the Firely SDK again on the Frontend? When it receives the FHIR data as JSON string, maybe you could use the FhirJsonParser to parse it into an object again?
Lars Ewert (Feb 11 2022 at 11:24):
Unfortunately there is not the same sdk for the Frontend. I know it is under construction at the moment. I tried to generate the API Endpoints with NSwag Studio, but that turned out to be a whole mess, since some Objects in .Net cant be converted correctly to Typescript Objects...
For now i will send the data as strings to the Frontend and let my frontend lib do the job with parsing values.
A short test worked fine and i had my properties needed.
Gino Canessa (Feb 11 2022 at 16:32):
Hi Lars, if you are using TypeScript for your frontend, you can use the JSON representation today. There are a few different libraries, but if you just need the types/structures/etc., you can use @types/fhir, which has the definitions for all the current published versions.
Lars Ewert (Feb 11 2022 at 17:52):
Hi Gino,
at the moment im using the .ToJson() function and return it as string to the frontend. Im using @types/fhir already and its working fine so far. ;-)
Gino Canessa (Feb 11 2022 at 18:26):
Great! In that case you will want to make sure you are using the correct serializer in C# and you should not have any missing data in TypeScript. The various pieces you are seeing that are 'ignored' in the SDK have to do with the transformation between the model definitions and the developer convenience.
For example, a 'string' type element in FHIR has extensions as a sibling on the parent, but the C# SDK puts them into the 'FhirString' type because that is how people like to access them.
Brian Postlethwaite (Feb 11 2022 at 20:44):
If you're doing front end typescript and backend c#, what are you using for the API controller, something you wrote?
And just including those firely SDK objects in your controller?
If so, that's the issue. As that would try and do the default dotnet parsers.
The fhir client object is for the client side usage.
There are a few options to do the server side too (using the Firely SDK and some others)
Lars Ewert (Feb 12 2022 at 14:56):
Hi Brian,
I wrote the Backend Controllers myself and yes im using the firely SDK Objects inside the Controller. Well which options do i have using another "server side"-lib? Have not found any Nuget-packages...
Or is it the better choice, to access the data from the Element properties and write the appropiate Interfaces in the Frontend to map these Elements?
To be honest, i dont know why there are siblings from the default properties and why the Objects from .NET HL7.FHir.R4 SDK and @fhir/types lib differ in that point. Only because people like to access them like that makes no sense in my opinion :D
But @Gino Canessa as you wrote earlier in another thread, there is a Frontend Lib in progress to close this gap.
Brian Postlethwaite (Feb 12 2022 at 16:16):
I put a controller on nuget/github that you could use - or check over the code in there and use the concepts in it.
It has the code to handle what's XML/JSON through custom handlers.
https://github.com/brianpos/fhir-net-web-api
There's an owin (full framework) and aspnetcore version of the library too
https://github.com/brianpos/fhir-net-web-api/tree/develop-r4/src/Hl7.DemoFileSystemFhirServer.AspNetCore
https://github.com/brianpos/fhir-net-web-api/tree/develop-r4/src/Hl7.Fhir.DemoFileSystemServer
https://www.nuget.org/packages/brianpos.Fhir.R4.WebApi.AspNetCore/3.7.0-beta1
Last updated: Apr 12 2022 at 19:14 UTC
