FHIR Chat · Beta release of new .NET API version · dotnet

Stream: dotnet

Topic: Beta release of new .NET API version


view this post on Zulip Ewout Kramer (Aug 04 2017 at 10:02):

Hi all, I have pushed a new release of the .NET API (0.92.5 for DSTU2/0.93.5 for STU3) in beta3 to nuget.

There are many, many bug fixes and performance improvements in this release, so this time I am publicly announcing this release, even though this is beta. I'd love you to test it out before I remove the "beta" moniker.

The most important changes are bug fixes to the FhirClient (it sometimes still acted as a DSTU2 client), performance improvements of about 20% to the validator (thanks Brian P!) and the introduction of 'async' for the FhirClient (thanks Ricardo!)

Find the full list of changes here: https://gist.github.com/ewoutkramer/8a066ccd7727cd6f5cd2282ae9b9a1d7

view this post on Zulip Ewout Kramer (Aug 04 2017 at 10:03):

I'd also like to emphasize that I still maintain both versions, so all new features appear in both STU3 and DSTU2!

view this post on Zulip Brian Postlethwaite (Aug 07 2017 at 04:31):

And Thanks to you too Ewout!

view this post on Zulip Ewout Kramer (Aug 30 2017 at 07:50):

I have just pushed beta4 for both DSTU2 and STU3. This beta4 contains two hotfixes:

  • A correction of constraint eld-16, which used an illegal regex escape - this validation error will no longer pop-up in your validation results
  • Improved handling of json files with non-fhir content in the directories managed by a DirectorySource

view this post on Zulip Ewout Kramer (Aug 30 2017 at 07:50):

  • And last but not least - a fix for the serializer under netstandard which caused internal data to pop up in coded elements

view this post on Zulip Paul Watt (Sep 05 2017 at 23:22):

  • And last but not least - a fix for the serializer under netstandard which caused internal data to pop up in coded elements

Probably not but I'm being hopeful, does this mean that custom serializers are no longer needed when directly adding an object to a document based database?

view this post on Zulip Christiaan Knaap (Sep 11 2017 at 19:04):

Do you mean de serialization of a document that has additional fields? You can configure the deserializer in the API to error on that or not. See the Hl7.Fhir.Serialization.ParserSettings argument to the FhirParser constructor.

view this post on Zulip Paul Watt (Sep 12 2017 at 05:46):

Sorry, should have said formatter rather than serializer. I expected that if I pushed a .net fhir object to a document database that the resulting json document should be the expected fhir json format. Instead it wasn't but creating custom formatters fixed this. I expect the above fix wasn't actually for this.

view this post on Zulip Michel Rutten (Sep 12 2017 at 16:28):

FHIR will always require custom serializers to handle polymorphic elements. Also see this (downvoted) change proposal:
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12522

view this post on Zulip Christiaan Knaap (Sep 12 2017 at 18:59):

For others that have this problem: Spark already solved this when saving to MongoDB. See https://github.com/furore-fhir/spark/blob/develop/src/Spark.Mongo/Store/BsonHelper.cs for the code (based on an old version of the Hl7.Fhir API).


Last updated: Apr 12 2022 at 19:14 UTC