Difference between revisions of "201805 Versioned API"
| Line 9: | Line 9: | ||
==Submitting WG/Project/Implementer Group== | ==Submitting WG/Project/Implementer Group== | ||
FHIR-I + ITS | FHIR-I + ITS | ||
| + | |||
| + | ==The Problem== | ||
| + | Many server operators and clients have been implemented on a variety of FHIR versions. In order to facilitate supporting newer versions of FHIR, it is necessary to work out mechanisms by which multiple FHIR versions can be supported side-by-side. Otherwise we run the risk of locking both vendors and consumers into legacy versions of FHIR due to the operational difficulty of migrating. | ||
| + | |||
| + | ==Approaches to Versioning== | ||
| + | |||
| + | ===URL versioning=== | ||
| + | The simplest approach to versioning is to include a version identifier in the URL of the FHIR server (e.g, `https://test.fhir.org/r4`). While this approach is easy to implement it suffers from several limitations. | ||
| + | Assuming a consuming service stores a reference to a patient as `iss=https://test.fhir.org/r4 ref=Patient/123` then several problems arise. | ||
| + | 1. The server operator needs to maintain that URL indefinitely or they run the risk of breaking consuming applications. | ||
| + | 2. The URL makes promises about the version, so the server operator would need to ensure that the url continued to serve resources in the appropriate version | ||
| + | 3. The client is also obligated to maintain the ability to read/write older versions of the FHIR standard as long as the record continues to point to the old version | ||
| + | 4. The FHIR version of the Resource is not semantically meaningful for the most part. Consuming applications really are interested in references to a particular resource and the FHIR version is a detail that needs to be worked out for communication. | ||
| + | 5. The sever operator needs to ensure that changes to a record are reflected in all supported versions, which may impose a high operational and support cost. | ||
| + | |||
| + | |||
==Justification== | ==Justification== | ||
Revision as of 06:52, 12 May 2018
WIP -- Work in Progress
Track Name
Versioned API
Submitting WG/Project/Implementer Group
FHIR-I + ITS
The Problem
Many server operators and clients have been implemented on a variety of FHIR versions. In order to facilitate supporting newer versions of FHIR, it is necessary to work out mechanisms by which multiple FHIR versions can be supported side-by-side. Otherwise we run the risk of locking both vendors and consumers into legacy versions of FHIR due to the operational difficulty of migrating.
Approaches to Versioning
URL versioning
The simplest approach to versioning is to include a version identifier in the URL of the FHIR server (e.g, `https://test.fhir.org/r4`). While this approach is easy to implement it suffers from several limitations. Assuming a consuming service stores a reference to a patient as `iss=https://test.fhir.org/r4 ref=Patient/123` then several problems arise. 1. The server operator needs to maintain that URL indefinitely or they run the risk of breaking consuming applications. 2. The URL makes promises about the version, so the server operator would need to ensure that the url continued to serve resources in the appropriate version 3. The client is also obligated to maintain the ability to read/write older versions of the FHIR standard as long as the record continues to point to the old version 4. The FHIR version of the Resource is not semantically meaningful for the most part. Consuming applications really are interested in references to a particular resource and the FHIR version is a detail that needs to be worked out for communication. 5. The sever operator needs to ensure that changes to a record are reflected in all supported versions, which may impose a high operational and support cost.
Justification
Interest is growing in how to manage cross-version use of the FHIR API. This connectathon stream tests out 2 aspects of cross-version use of the FHIR API:
a single end-point that supports more than one version (Scenarios #1 and #2) how to handle changes a resource between versions (Scenarios #3 and #4)
Proposed Track Lead
Kevin Olbrich See Connectathon_Track_Lead_Responsibilities
Expected participants
Kevin Olbrich (McKesson)
Roles
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
Role 1 Name
Scenarios
Scenario Step 1 Name
- Action:
- Precondition:
- Success Criteria:
- Bonus point:
