For each ResourceType, we can find applicable extensions (context https://build.fhir.org/defining-extensions.html#context field in the extension SD). This allows us to generate an artificial profile, which will provide a nice and easy way to get and set applicable extensions. Let's see how it works with a regular profile (https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-patient.html and https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-race.profile.json.html):
const patient = { resourceType: "Patient" };
const patientProfile = new USCorePatientProfileProfile(patient);
patientProfile
.setRace({
ombCategory: {
system: "urn:oid:2.16.840.1.113883.6.238",
code: "2106-3",
display: "White",
},
text: "White",
})
We can automatically generate the same thing for arbitrary extensions without any additional constraints.
const patient = { resourceType: "Patient" };
const patientExtensions = new PatientExtensionProfile(patient);
patientExtensions
.setRace({
ombCategory: {
system: "urn:oid:2.16.840.1.113883.6.238",
code: "2106-3",
display: "White",
},
text: "White",
})
Artificial profiles should work very well because they can be performed at the TypeSchema level, so they will automatically provide support for all generators that support profiles.
Open problems:
- Extension name: by default we can get
sd.name, but in case of name collisions or GUID-like strings, we can extract it from the URL, etc.
- Provide the user control over extension naming as part of generator configuration.
- Number of applicable extensions:
- Explicitly configure extensions related to ResourceType
- Limit the maximum number of extensions in
<ResourceType>ExtensionProfile
- Inheritance in
sd.context which can be applicable for any element:
- Primitive type and Element extensions
For each ResourceType, we can find applicable extensions (context https://build.fhir.org/defining-extensions.html#context field in the extension SD). This allows us to generate an artificial profile, which will provide a nice and easy way to get and set applicable extensions. Let's see how it works with a regular profile (https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-patient.html and https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-race.profile.json.html):
We can automatically generate the same thing for arbitrary extensions without any additional constraints.
Artificial profiles should work very well because they can be performed at the TypeSchema level, so they will automatically provide support for all generators that support profiles.
Open problems:
sd.name, but in case of name collisions or GUID-like strings, we can extract it from the URL, etc.<ResourceType>ExtensionProfilesd.contextwhich can be applicable for any element: