Stream: dotnet
Topic: C# classes representing profiles
Johannes Höhn (Jan 11 2019 at 08:45):
Is there some possibility to generate classes, that represent resources under profiles? Profiles can have different cardinalities, so seeing it in code how an object is supposed to look can be quite helpful.
Brian Postlethwaite (Jan 11 2019 at 08:55):
The classes don't change, although a profile can reduce the cardinality, it is still a collection or not on the wire.
You could think of the profile as custom validation business rules on the core resources (hence you'll not that each property has the extension item under the element base class)
Michele Mottini (Jan 11 2019 at 11:46):
(this keeps coming up - maybe worth some explanation somewhere in the specs? )
Brian Postlethwaite (Jan 11 2019 at 22:02):
At least in the dotnet docs or someone's blog.
Michele Mottini (Jan 11 2019 at 22:28):
Not dotnet specifically - recently I saw the same question asked about HAPI
Michele Mottini (Jan 11 2019 at 22:29):
There seems to be a general assumption that to work with a specific profile you need tailored classes - that is not the way things work (or should work)
Brian Postlethwaite (Jan 12 2019 at 01:47):
True, but think does deserve to be where the devs are looking.
At least a paragraph summarising on the NuGet package docs and reference somewhere with detailed notes.
Vadim Peretokin (Jan 16 2019 at 09:34):
While that is technically true, I agree with @Johannes Höhn - if a profile restricts the max cardinality to 1, there's no reason you should work with a list of size 1 in the API.
Vadim Peretokin (Jan 16 2019 at 09:35):
It's more confusing than helpful.
Michel Rutten (Jan 17 2019 at 09:48):
I guess it depends ;p The FHIR API provides generic and reusable PoCo classes, these require a common structure (with property type and cardinality) for all kinds of reasons, such as serialization. However it is entirely possible to author (derive) custom classes for specific profiles and targeted to specific use cases, manually or using code generation. Such custom classes could then implement additional convenience properties for list elements with cardinality constrained to a single element.
Bob Barnard (Feb 05 2019 at 13:39):
I guess it depends ;p The FHIR API provides generic and reusable PoCo classes, these require a common structure (with property type and cardinality) for all kinds of reasons, such as serialization. However it is entirely possible to author (derive) custom classes for specific profiles and targeted to specific use cases, manually or using code generation. Such custom classes could then implement additional convenience properties for list elements with cardinality constrained to a single element.
Very interested in this capability as we are working heavily on profiles and extensions. Is there indeed a way to add some structure definitions and regenerate from them....to get new CodeGenerated POCOs? It seems that all the building blocks are in the HL7.FHIR API, but I dont quite see any tests or docs that explain how we can add our own profiles, ideally to get our own POCOs.
Bob Barnard (Feb 05 2019 at 14:42):
Or....put another way....if we CANT generate POCOs for our profiled resources, what is the process for using profile instances w/ the HL7.FHIR API? If I wanted to, say, create an instance of BMI (derives from Observation), how does one do that? Ultimately if we can define profiles and interact w/ them via strongly typed code then we get the same benefits as being able to generate POCOs for our profiled resources. Thanks!
Michele Mottini (Feb 05 2019 at 14:52):
create an instance of BMI (derives from Observation)
Michele Mottini (Feb 05 2019 at 14:52):
You just use the existing Model.Observation class
Bob Barnard (Feb 05 2019 at 15:10):
what makes it a BMI? The constructor doesnt seem to take the profile.
Michele Mottini (Feb 05 2019 at 16:13):
The fact that you respect the rules of the BMI profile: fill the elements that need to be filled, use the right value sets etc.
Michele Mottini (Feb 05 2019 at 16:14):
(and set the profile in the Meta element - although I do not think this is strictly needed)
Bob Barnard (Feb 05 2019 at 16:53):
Hmmmm....so there is no way to get strong typing based on the profile (e.g. all of the constraints)? It really does seem then like a nice feature to add to this API would be the ability of consumers to add their own StructureDefinition and then re-run whatever generation process exists so that we can have our own derived profile resources and SEE our constraints/extensions on POCOs. I don't suppose anyone knows how the generation process works...I may be able to add that functionality myself, but I'm struggling to see how to regenerate classes from the source profiles
Grahame Grieve (Feb 05 2019 at 18:50):
it's not so simple because a resource can conform to multiple different profiles at once. And there's no particular way to know whether a resource conforms to a profile than to test to see whether it conforms to a particular set of rules
Grahame Grieve (Feb 05 2019 at 18:51):
it's better to generate a profile is an interface/facade to the underlying resource
Grahame Grieve (Feb 05 2019 at 18:51):
but no one has generated these yet, either in java or c#, so far as I know
Michel Rutten (Feb 06 2019 at 12:29):
Strong typing based on (generic) profiles implies that all profile constraints can be verified at compile time. That is quite a challenging problem, to say the least. @Mark Kramer has been working on generating code and FHIR profiles from an abstract syntax, he might be able to shed some light on this.
However within the scope of a limited use case, say a small mobile app, it would be feasible to manually author custom PoCo classes for relevant profiles, to facilitate app developers. You can easily subclass existing PoCo's. Alternatively, you could implement your own custom PoCo classes based on the new ITypedElement layer.
Martin Andersen (Mar 06 2019 at 18:16):
I have been struggling a bit with this issue as well. Are there any way that one could contribute to the fhir-net-api docs?
Last updated: Apr 12 2022 at 19:14 UTC
