Trying to add subclass to a Fhir.Net Resource and have it serialize?

Question

Because a partner we are trying to setup FHIR communications is using an in-between version of the FHIR schema, they are sending and expecting a Practitioner/PractitionerRoleComponent that has an organization element, instead of an managingOrganization which the FHIR.NET API is expecting.

I've subclassed the Practitioner and PractitionerRoleComponent and got the objects creating fine, so Practitioner now has a custom THXPractitionerRole in our case. No errors are encountered, I have all attributes in place in the subclass (see below).

However, when I serialize to XML, the results have no PractitionerRole at all -- it almost seems like the serializer is just totally ignoring it. I'm going to guess that the FHIR.Net Serializers have some sort of check to make sure they are only serializing valid FHIR types? Or is there anything I'm missing from the subclass that might be preventing it from working?

The API I'm talking about is here: https://github.com/ewoutkramer/fhir-net-api/tree/develop

The goal is to be able to have a Practitioner/practitionerRole/organization element in the resulting XML/Json.

[FhirType("Practitioner", IsResource = true)]
[DataContract]
public partial class THXPractitioner : Hl7.Fhir.Model.Practitioner, System.ComponentModel.INotifyPropertyChanged
{
    [FhirElement("practitionerRole", Order = 170)]
    [Cardinality(Min = 0, Max = -1)]
    [DataMember]
    public List<THXPractitionerRoleComponent> THXPractitionerRole
    {
        get { if (_PractitionerRole == null) _PractitionerRole = new List<THXPractitionerRoleComponent>(); return _PractitionerRole; }
        set { _PractitionerRole = value; OnPropertyChanged("PractitionerRole"); }
    }
    private List<THXPractitionerRoleComponent> _PractitionerRole;


    [FhirType("PractitionerRoleComponent")]
    [DataContract]
    public partial class THXPractitionerRoleComponent : Hl7.Fhir.Model.Practitioner.PractitionerRoleComponent, System.ComponentModel.INotifyPropertyChanged, IBackboneElement
    {
        [NotMapped]
        public override string TypeName { get { return "PractitionerRoleComponent"; } }

        /// <summary>
        /// Organization where the roles are performed
        /// </summary>
        [FhirElement("organization", Order = 40)]
        [References("Organization")]
        [DataMember]
        public ResourceReference organization
        {
            get { return _organization; }
            set { _organization = value; OnPropertyChanged("organization");}
        }

        private ResourceReference _organization;
}

Here's where it gets called:

fhirpractitioner.THXPractitionerRole = new List<Model.THXPractitioner.THXPractitionerRoleComponent>()
        {
            new Model.THXPractitioner.THXPractitionerRoleComponent()
            {
                Extension = new List<Extension>()
                {
                      new Extension()
                      {
                          Url = "[My Url]",

                      }
                },
                organization = new ResourceReference()
                {
                     Reference = "asdfasfd"
                     ,Display = "organization"
                     ,DisplayElement= new FhirString("organization")
                }
            }
        };

Answer 1

A colleague of mine ended up finding this "issue" on GitHub for the project:

https://github.com/ewoutkramer/fhir-net-api/issues/337

So, I ended up taking a copy of the library and following the ideas suggested in the issue thread and recompiled. We now have a custom library.

From the issue:

the only way to handle custom resources currently is to create a StructureDefinition for it, add it to the profiles-resources.xml file in the Model/Source directory, and rerun the T4 templates - you'll get your own version of the .NET library, with a POCO for your own resources....

I did this, had to delete the Generated/Practitioner.cs file before running Template-Model.tt via the Run Custom Tool context menu option in Visual Studio. Once that completed, the Practitioner.cs file was generated with our new/custom resource and the Library was able to serialize it into the XML we needed.