-
Notifications
You must be signed in to change notification settings - Fork 157
Proposed breaking changes
Drop support for Java 8 as a compile/runtime target. (was: Switch to the latest OpenJ9 LTS.)
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.
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.
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.
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
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
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?
Mostly changes javax to jakarta packages...maybe a few unexpected surprises
See https://github.com/LinuxForHealth/FHIR/issues/3206
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?
Go all-in on FHIR AuditEvent However, note that AuditEvent is not normative and has significant edits proposed for R5.
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.
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"
]
},
...
}
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
FHIR® is the registered trademark of HL7 and is used with the permission of HL7. Use of the FHIR trademark does not constitute endorsement of this product by HL7.
IBM and the IBM logo are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on ibm.com/trademark.