FHIR offers many improvements over existing health care standards, including “support for RESTful architectures”.
REST is an architectural style, driven by a need to interoperate between:
- Diverse systems (built using many different languages, running on different platforms).
- Many (relatively) new device types (PCs, laptops, phones, tablets, wearables, monitors etc.).
- Cloud based systems (taking advantage of elastic scale).
The RESTful architectural style is underpinned by a number of properties:
- Heterogony (interoperating with many clients and services, regardless of language or platform).
Modern healthcare systems need to support diverse systems such as clinical systems, administrative systems, desktop and mobile based professional systems and also patient systems such telecare systems and cloud based PHRs that run on mobile phones, web browsers and devices / wearables.
Each of these systems is likely to be deployed at different times / release frequencies. For example, clinical systems and embedded telecare systems may be on a relatively long upgrade cycle (months or years between version upgrades), whereas web-based applications using CI/CD pipelines, may update on a daily basis.
Services and clients need to be able to evolve independently, without running the risk of making each other unstable due to versioning incompatibilities. This evolvability property is missing in FHIR, forcing an unmanageable coupling between clients and services.
In a follow up post, I’ll be laying out how I think FHIR can take advantage of REST’s uniform interface as the contract – enabling versioning within a representation, versioning the representation itself and also versioning resources. This will allow services and clients to evolve independently (upgrade in their own time), thereby achieving this important RESTful property.