Stream: dotnet
Topic: T4 and profiles
Kim Ruben Vatnehagen (May 29 2019 at 11:58):
Hey all :)
We're trying to mentally bridge the gap between pocos(models) and structure definitions.
As such we are using Forge to create/edit profiles and then using the .net r4 codebase and the T4 template in there to generate pocos.
I'd like to think that there would be some way to transform the differentials created by forge to a format that is somewhat like what the .net build pulls from build.fhir.org.
If anyone has any insight into that process, it'd be awesome to have a talk :)
Oh, btw, we are implementing the Norwegian profiles as they are modified and created.
Michele Mottini (May 29 2019 at 12:42):
Don't generate different classes for the profile, the standard classes support any profile (and they are those that clients are already using)
Kenneth Myhra (May 29 2019 at 12:48):
As Michele says, you would use the POCOs as they are in the .net API. If you haven't already done so take a look at the docs for the .net API on simplifier: http://docs.simplifier.net/fhirnetapi/index.html
If you want validation you will do that based on the StructureDefinitions. Take a look at the validation tests in the library: https://github.com/FirelyTeam/fhir-net-api/tree/develop-stu3/src/Hl7.Fhir.Specification.Tests/Validation.
Brian Postlethwaite (May 29 2019 at 20:53):
One thing I've considered was to do something like this to create wrapper classes, or extension methods to provide convenient access to the POCOs that already support the profiled content.
To then get compiler warnings etc.
Brian Postlethwaite (May 29 2019 at 20:53):
The reason not wanting to change the base type is that a single resource could conform to multiple profiles, and never really know which you want to work with ahead of time when you're parsing the content into a POCO.
Last updated: Apr 12 2022 at 19:14 UTC
