Update fhir-ig-us-core to US-Core STU4

[prb112]

Update fhir-ig-us-core to US-Core STU4

Related to #1309

[prb112]

Per #2551 (comment)

Q: What we should do with the technical corrections?
A: ... Hybrid approaches are fine... when we hit the technical corrections.
Let's start up with Major.Minor as individual models. (Could also consider stu3, stu4, r4)

fhir-ig-us-core-stu3 (3.1.0, 3.1.1)
fhir-ig-us-core-stu4 (4.0.0, 4.1.0)

Net: Hybrid approach?

Option 1: Multiple IG versions in a single project / jar (as long as you can exclude and set a default)

Embed the version in the package hierarchy hl7/us/core/stu3/package

[prb112]

move the examples to src/test/resources with a version level.

[lmsurpre]

To QA we should confirm that validating against 3.1.1 doesn't accidentally pull in any of the 4.0.0 resources.

[lmsurpre]

To validate this one, I added the following methods to USCore400ResourceProvider:

    @Override
    public
    FHIRRegistryResource getRegistryResource(Class<? extends Resource> resourceType, String url, String version) {
        FHIRRegistryResource registryResource = super.getRegistryResource(resourceType, url, version);
        return registryResource == null ? null : new FHIRRegistryResourceWrapper((PackageRegistryResource)registryResource);
    }

    @Override
    public
    Collection<FHIRRegistryResource> getRegistryResources(Class<? extends Resource> resourceType) {
        return super.getRegistryResources(resourceType).stream()
                .map(rr -> new FHIRRegistryResourceWrapper((PackageRegistryResource)rr))
                .collect(Collectors.toSet());
    }

    @Override
    public
    Collection<FHIRRegistryResource> getRegistryResources() {
        return super.getRegistryResources().stream()
                .map(rr -> new FHIRRegistryResourceWrapper((PackageRegistryResource)rr))
                .collect(Collectors.toSet());
    }

    @Override
    public
    Collection<FHIRRegistryResource> getProfileResources(String type) {
        return super.getProfileResources(type).stream()
                .map(rr -> new FHIRRegistryResourceWrapper((PackageRegistryResource)rr))
                .collect(Collectors.toSet());
    }

    @Override
    public
    Collection<FHIRRegistryResource> getSearchParameterResources(String type) {
        return super.getSearchParameterResources(type).stream()
                .map(rr -> new FHIRRegistryResourceWrapper((PackageRegistryResource)rr))
                .collect(Collectors.toSet());
    }

    @Override
    public
    Collection<FHIRRegistryResource> getProfileResources() {
        return super.getProfileResources().stream()
                .map(rr -> new FHIRRegistryResourceWrapper((PackageRegistryResource)rr))
                .collect(Collectors.toSet());
    }

    public static class FHIRRegistryResourceWrapper extends PackageRegistryResource {

        public FHIRRegistryResourceWrapper(PackageRegistryResource rr) {
            super(rr.getResourceType(), rr.getId(), rr.getUrl(), rr.getVersion(), rr.getKind(), rr.getType(), rr.getPath());
        }

        @Override
        public Resource getResource() {
            System.err.println("Unexpected load of " + resourceType.getSimpleName() + " " + id + " [" + url + "]");
            return super.getResource();
        }
    }

I then executed the v311 ProfileTest, did some touchup, and noted all the US Core 4.0.0 resources that got loaded:

unexpected load of CodeSystem cdcrec [urn:oid:2.16.840.1.113883.6.238]
unexpected load of CodeSystem condition-category [http://hl7.org/fhir/us/core/CodeSystem/condition-category]
unexpected load of StructureDefinition us-core-birthsex [http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex]
unexpected load of StructureDefinition us-core-direct [http://hl7.org/fhir/us/core/StructureDefinition/us-core-direct]
unexpected load of StructureDefinition us-core-ethnicity [http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity]
unexpected load of StructureDefinition us-core-race [http://hl7.org/fhir/us/core/StructureDefinition/us-core-race]
unexpected load of ValueSet birthsex [http://hl7.org/fhir/us/core/ValueSet/birthsex]
unexpected load of ValueSet detailed-ethnicity [http://hl7.org/fhir/us/core/ValueSet/detailed-ethnicity]
unexpected load of ValueSet detailed-race [http://hl7.org/fhir/us/core/ValueSet/detailed-race]
unexpected load of ValueSet omb-ethnicity-category [http://hl7.org/fhir/us/core/ValueSet/omb-ethnicity-category]
unexpected load of ValueSet omb-race-category [http://hl7.org/fhir/us/core/ValueSet/omb-race-category]

The StructureDefinitions are extensions and it is working as designed for those to be validated against the latest version (see https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Can.20.2F.20should.20an.20Extension.2Eurl.20contain.20an.20optional.20version.3F for more detail).

Further, those newer extension definitions are pulling in the newer ValueSets.

The CodeSystem ones were also deemed acceptable because we found that if the test resource instance contains a Coding.version of 3.1.1 then we validate the code against the 3.1.1 code system instead.