Versioning
This page should give some guidance about versioning of the contents within the OMI context. Different use cases require different approaches to versioning. Omi differentiates two modes of Versioning:
- Correction/Fix: minor changes in the metadata of the Algorithms or any of the related resources
- New releases: Introducing a new release of an existing Algorithm to the OMI registry
While 1. can be handled within the FHIR Specification via the Resource history, 2. is a different mode of operation that requires the creation of new resources including references. The following figure illustrates this.
Note: each new Version of an Algorithm (Device) needs a new set of resources (HealthcareServices, Endpoint, Organization, Parameters) associated to it since compatibility cannot be assured otherwise.
The upcoming table outlines the handling of the use cases as well as their consequences and provides a short reasoning for why we pursued this approach.
| Use case | Consequence | Reasoning |
|---|---|---|
| Something within the Device Resource has to be fixed (e.g. Typo in the model name) | A new version of the Device resource is persisted. This can be achieved using the FHIR Resource history of the Device resource. | Changes in the meta information of the Algorithm can occur frequently |
| A new version of the BOA Model is released and should be offerend in the OMI Registry | * A new Device Resource is created * New Input-/ Output Parameter resources have to be created, or copied from lower versions * HealthcareServices resources have to be updated (e.g. link to the new version of the Device) or created * Organization resources have to be linked correctly * Endpoint Resources have to be created and linked appropriately |
A new released version of an algorithm (Device) has to be a new set of resources, since we cannot assure integrity over different Resources and their respective versions in FHIR. |