-
Notifications
You must be signed in to change notification settings - Fork 3
Description
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.contextwhich can be applicable for any element: - Primitive type and Element extensions