Stream: committers
Topic: fhir_version valueset normative
Brian Postlethwaite (Nov 03 2018 at 09:11):
Is this valueset really going to be normative?
http://build.fhir.org/valueset-FHIR-version.html
I think it needs to be extensible, and obviously needs to be changed for publishing the final version.
And if the CapabilityStatement doesn't change, how can it be a required binding to exactly this valueset, and not extensible to add in the new versions as they are built?
(picked this up doing the code generation for the .net libs)
@Grahame Grieve, @Lloyd McKenzie, @Ewout Kramer
Brian Postlethwaite (Nov 03 2018 at 11:18):
// Generated Shared Enumeration: FHIRVersion
// Used in model class (resource): CapabilityStatement.fhirVersion
// Used in model class (resource): ImplementationGuide.fhirVersion
// Used in model class (resource): ImplementationGuide.definition.resource.fhirVersion
// Used in model class (resource): StructureDefinition.fhirVersion
Brian Postlethwaite (Nov 03 2018 at 11:23):
While I'm reviewing the technical artifacts, is it a problem that the canonicalURI for the Medication Status CODE SYSTEM has ValueSet in it? http://build.fhir.org/codesystem-medication-statement-status.html
This was changed since the Sept Ballot version
Brian Postlethwaite (Nov 03 2018 at 11:35):
These are the only changes that are going to mess with the code generation for c# right now.
(not 100% sure why its causing the code generator a problem, but thought its weird that it changed like it did)
Lloyd McKenzie (Nov 03 2018 at 14:32):
It's not extensible in the sense that you're not allowed to add your own codes - only a new version of the spec can add a new code. In your software, you'll treat it the same as you would AdministrativeGender or ObservationStatus. It's possible you could receive an instance from a new version of the specification that conatains a code you don't recognize. If you want to be permissive of future versions, you'll need to handle that.
Grahame Grieve (Nov 03 2018 at 19:28):
The change to fhir version from string to code is a big deal for code generators. But it’s not and shouldn’t be extensible
Brian Postlethwaite (Nov 03 2018 at 19:49):
Means that will always need the same version of conformance resources to be able to handle this with the .net fhir client.
Brian Postlethwaite (Nov 03 2018 at 19:52):
Fixed binding with required valueset goes to enumeration with code type.
Lloyd McKenzie (Nov 03 2018 at 23:10):
That's going to pose a problem generally for supporting future versions - how will you handle a new status code?
Brian Postlethwaite (Nov 04 2018 at 00:19):
Yes, if this is the way its expected to work, I've posed the question in the fhir net client chat.
Brian Postlethwaite (Nov 04 2018 at 00:20):
And why I raised it as a concern to ensure that the impact was understood, its not working how I thought, so now moved the problem to the netclient
Last updated: Apr 12 2022 at 19:14 UTC
