Proposed breaking changes (wish list)

Good Ideas

Java [4.11]

Drop support for Java 8 as a compile/runtime target. (was: Switch to the latest OpenJ9 LTS.)

FHIRPersistence [4.11]

We introduced new flavors of create and update (createWithMeta and updateWithMeta). We should remove the old ones.

Whole system history also adds new options to the FHIRPersistence changes API. We should remove the old ones.

Drop support for Export to Parquet [4.11]

We already ship with it disabled and we opened https://github.com/LinuxForHealth/FHIR/issues/3139 to further mark it deprecated. See https://github.com/LinuxForHealth/FHIR/issues/3070 for one reason we might want to remove it entirely. Having folks transform from NDJSON to Parquet seems like a suitable replacement. We could even write a spark job that does that for them if we really want.

Implement https://github.com/LinuxForHealth/FHIR/issues/2026 [4.11]

This changes the default external behavior of our whole-system-history endpoint, so it would be good to fold it into a major release bump.

Remove profile examples from fhir-examples [partially done in 4.11]

We've moved to packaging these under src/test/resources of the individual IG projects under conformance, so I think we should go all in on that and remove them from fhir-examples.

Make skippable updates (update-only-if-modified) behavior the default [5.0]

Originally added for https://github.com/LinuxForHealth/FHIR/issues/2263 the server will skip updates if the resource content hasn't changed and the user opts in via the X-FHIR-UPDATE-IF-MODIFIED header. There seems to already be broad support for this idea in the community (e.g. https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Handling.20of.20Updates/near/270802907 ) and so I think we could remove the client opt-in and just make this the default behavior for 5.0 https://github.com/LinuxForHealth/FHIR/issues/3614

Unify the FHIRResourceType and ResourceType code subtypes [5.0]

We name the code subtypes by the binding name from the resources which have a required binding to them. In the case of FHIRResource and ResourceType, the binding names are different but they actually target the same valueset...leading to this ugly duplication in our generated model. Because this one is used pretty widely, I think it makes sense for special logic. I propose 'ResourceTypeCode' for the name. https://github.com/LinuxForHealth/FHIR/issues/3289

Future stuff

Drop support for the OAUTH schema

fhir-persistence-schema currently creates the OAUTH schema by default if you run --create-schemas and updates it when you run --update-schema

over time, we've removed most of the documentation for using liberty as an oauth provider (which is the only case where this schema is needed) and instead we point to use of an external OIDC provider like Keycloak. maybe its time to remove the oauth-related schema features, or at least avoid creating them by default?

Move to JakartaEE 9 specs/dependencies

Mostly changes javax to jakarta packages...maybe a few unexpected surprises

Change from CXF to RESTEasy

See https://github.com/LinuxForHealth/FHIR/issues/3206

Split system config from tenant config

Today we have system-level config and tenant-specific config mixed together in a single file with a table at https://ibm.github.io/FHIR/guides/FHIRServerUsersGuide#513-property-attributes to define which is which.

However we also treat the "default" config as its own tenant and there is no way to disable that. I think it would make more sense to have system config in one file and tenant config in a separate file. Maybe 'enableMultitenancy' could be a new config property in the system config and only then would we look for the tenant config?

Crazy Ideas

Drop support for CADF

Go all-in on FHIR AuditEvent However, note that AuditEvent is not normative and has significant edits proposed for R5.

Drop support for Db2 [5.0]

The Db2 implementation was originally designed for running a multi-tenant cloud service. Supporting multiple tenants per schema adds a lot of complexity. We've had https://github.com/LinuxForHealth/FHIR/issues/840 open for adding a simpler flavor of Db2 support (more in line with our postgresql implementation) for a long while, but I think most users of our 4.x line are just using PostgreSQL anyway.

The potential gains (in terms of simplicity) for dropping db2 support is probably not even as strong an argument as the reduction in testing burden. I opened https://github.com/LinuxForHealth/FHIR/issues/3676 for it.

Support configurable RBAC

Introduce configurable role-based access control for resource interactions and extended operations. Currently we support per-resource-type interaction filters like this:

"resources": {
    "open": false,
    "Condition": {
        "interactions": ["create", "update", "read", "vread", "history", "search"]
    },
    "Observation": {
        "interactions": ["create", "read", "vread", "history", "delete"]
    },
    "Medication": {
    }
    ...

What might be interesting is to introduce role-based controls so that might become something like this:

"resources": {
    "open": false,
    "Condition": {
        "interactions": {
            "create": ["Practitioners"],
            "update": ["Practitioners"],
            "read": ["FHIRUsers"], 
            "vread": ["FHIRUsers"],
            "history": ["FHIRUsers"],
            "search": ["FHIRUsers"]
        }
    },
    "Observation": {
        "interactions": {
            "create": ["*"],
            "read": ["FHIRUsers"],
            "update": ["MyCustomRole"],
            "vread": ["MyCustomRole"],
            "history": ["MyCustomRole"],
            "delete": ["FHIRAdmin"]
        }
    },
    "Medication": {
        "interactions": {
            "create": ["FHIRUsers"],
            "read": ["EVERYONE"],
            "search": ["EVERYONE"]
        }
    }
    ...

Or possibly based on security labels:

    "security": {
        "cors": true,
        ...
        "labelRoles" {
            "http://terminology.hl7.org/CodeSystem/v3-Confidentiality|U": ["FHIRUsers"],
            "http://terminology.hl7.org/CodeSystem/v3-Confidentiality|R": ["FHIRAdmin"],
        }
    }

We already have something like this for the $erase operation, and I think we could extend it to include all other extended operations as well:

        "operations": {
            "erase": {
                "enabled": true,
                "allowedRoles": [
                    "FHIROperationAdmin",
                    "FHIRUsers"
                ]
            },
            "healthcheck": {
                "enabled": true,
                "allowedRoles": [
                    "FHIROperationAdmin",
                    "FHIRUsers"
                ]
            },
            "healthcheck": {
                "enabled": true,
                "allowedRoles": [
                    "FHIROperationAdmin",
                    "FHIRUsers"
                ]
            },
            ...
        }

Reorganize project modules

for example:

build
bulk
  fhir-bulkdata-webapp
conformance
  fhir-ig-carin-bb
  fhir-ig-davinci-hrex
  fhir-ig-davinci-pdex
  fhir-ig-davinci-pdex-formulary
  fhir-ig-davinci-pdex-plan-net
  fhir-ig-mcode
  fhir-ig-spl
  fhir-ig-us-core
  fhir-ig-vhdir
  fhir-profile
  fhir-registry
  fhir-validation
core
  fhir-cache
  fhir-core
  fhir-config
  fhir-model
  fhir-path
  fhir-provider
cql
  fhir-cql
  fhir-cql-server
  operation
    fhir-operation-apply
    fhir-operation-cpg
    fhir-operation-cqf
  fhir-cql-rest
  fhir-quality-measure
demo
docs
fhir-audit
fhir-client
fhir-examples
fhir-install
fhir-openapi
fhir-smart
persistence
  fhir-database-utils
  fhir-persistence
  fhir-persistence-cassandra
  fhir-persistence-cos
  fhir-persistence-jdbc
  fhir-persistence-schema
  fhir-persistence-scout
server
  fhir-search
  fhir-server
  fhir-server-spi
tooling
  fhir-bucket
  fhir-examples-generator
  fhir-swagger-generator
  fhir-tools
operation
  fhir-operation-bulkdata
  fhir-operation-convert
  fhir-operation-document
  fhir-operation-erase
  fhir-operation-everything
  fhir-operation-healthcheck
  fhir-operation-member-match
  fhir-operation-member-match-demo
  fhir-operation-reindex
  fhir-operation-test
  fhir-operation-validate
performance
  fhir-benchmark