FHIR is a modern, model-driven approach to connecting healthcare systems and applications. As a healthcare data interoperability standard, it's designed to be easy to implement and use and builds on technologies like HTTP, REST, and JSON.
Everything in FHIR is centered around resources (FHIR resources)—discrete pieces of data that represent real-world entities and concepts. Examples of FHIR resources are Patient, Observation, and MedicationRequest.
Commonly, FHIR resources are exchanged through pushing and pulling data from clinical data repositories a.k.a. FHIR servers.
FHIR servers are data repositories that store FHIR resources. There are many implementations of FHIR servers, including HAPI FHIR, LinuxForHealth FHIR Server, and others, as well as cloud offerings like Azure API for FHIR and Google Cloud Healthcare API.
While under the hood different FHIR servers may use different storage technologies, table schemas, etc. (or none), they all implement the same, standard RESTful API for accessing and manipulating FHIR resources.
FHIR's REST API is the core part of the FHIR specification besides the FHIR resource models and type framework.
The API follows a common convention for structuring API routes (the de facto standard structure for RESTful APIs). In this convention, the resource URLs are made of the resource type and ID, separated by a forward slash—e.g. /Patient/123 for a Patient resource with the ID 123—while URLs like /Patient and /Observation represent the collections of resources of a specific type.
The URL structure of the API implies a simple hierarchy of resources and suggests that within FHIR servers, the resources are organized in collections by type. This principle gave me an idea for a "resource/object tree"-style viewer for FHIR servers (demo below).
As a FHIR client application, the demo works by querying the FHIR server's API. You only need to provide the base URL of the FHIR server (the base FHIR endpoint).
To discover the capabilities of the server and get the list of the supported resource types, the demo queries the server's /metadata endpoint. This endpoint returns a CapabilityStatement resource (the server's "manifest") which sometimes also includes the resource count for each resource type.
Made by Anton Vasetenkov.
If you want to say hi, you can reach me on LinkedIn or via email. If you like my work, you can support me by buying me a coffee.