Features include:
- FHIR profiles are defined for Task, Organization, Endpoint, ResearchStudy and Group resources. All resources are validated on create or update via the REST API. The CapabilityStatement now lists supported FHIR profiles.
- Access to FHIR resources is now dependent on access control rules. Resources can either be allowed by location (local or remote access) or based on the resource referencing the users organization.
- Authorization to execute or continue a process via Task resources is now dependent on the users organization type (MeDIC - medical data integration center or TTP - trusted third party) and location (local, remote). Allowed combinations of recipient, and requester are configured via ActivityDefinition resources while also defining the expected Task profile.
- Missing aspects of the FHIR HTTP API implemented: Content of Binary resources can now be directly created, updated and downloaded via content negotiation (HTTP headers Content-Type and Accept), see Binary. History URLs are now supported and a 'deleted' version is correctly created when a resource is Deleted, see history. HTTP header Prefer is now supported to set strict or lenient search parameter parsing, see handling errors, as well as minimal (status code only), representation (created/updated resource) or OperationOutcome (may include validation warnings) results in responses of create and update operations, see REST API.
- Logical references are now resolved and if resolvable additionally stored as literal references in the database for searching. Resolved literal references are remove again before returning a resource to the user.
- Modifies the feasibility query process: Feasibility queries are always send to every participating organisation. The aggregation of the individual results of each organisation is now performed by the TTP, so that no MeDIC can know any other MeDICs result. Feasibility results will only be released by the TTP if more than 3 organisations responded. Feasibility queries can be executed with local patient consent checks and cross organization privacy preserving record linkage.
- A new plugin interface allows for different Master Patient Index clients, depending on the supported Master Patient Index of an organisation.
- Adds a Master Patient Client IHE PDQ implementation based on HL7 v2 Messages using client certificate authentication.
- Multi-stage Docker builds are used to minimized the number of layers for the fhir and bpe (business process engine) containers.
- Library dependencies upgraded to latest versions where applicable.
- Continues integration builds migrated from travis to GitHub Actions.
Docker containers for this release can be access via the GitHub Docker registry:
- bpe: docker.pkg.github.com/highmed/highmed-dsf/bpe:0.2.0
- bpe_proxy: docker.pkg.github.com/highmed/highmed-dsf/bpe_proxy:0.2.0
- fhir: docker.pkg.github.com/highmed/highmed-dsf/fhir:0.2.0
- fhir_proxy: docker.pkg.github.com/highmed/highmed-dsf/fhir_proxy:0.2.0
Issues closed:
- Enable Download of Missed Task Resources in BPE Server #105
- Enable Startup of BPE without a running FHIR Server #104
- Upgrade Dependencies for 0.2.0 Release #103
- Modify DELETE Implementation to Comply with FHIR REST API #99
- Implement FHIR _history #97
- Implement MPI client #91
- Migrate from travis to GitHub Actions #88
- Minimize Layers Created by fhir and bpe Docker Builds #84
- Integrate Record Linkage and Pseudonymization Services into Feasibility Process #79
- Adapt simple feasibility for new Requirements #68
- Use conditional create for resources in bundles that don't change #67
- Snapshot generation results in incomplete snapshots if differential not based on FHIR base profile #45
- Snapshot generation fails for Task resources #43
- Add supported Fhir profiles to the CapabilityStatement #27
- Implement Binary resource #10
- Add validation for HiGHmed profiles #8