A Complete Guide To FHIR Resources & FHIR API
The FHIR standard is designed to enable healthcare information exchange that completely supports providing healthcare for worldwide use and in a huge variety of environments.
The FHIR standard is implemented on top of the HTTPS protocol and adapts widely used RESTful practices to provide interoperability for integrated healthcare services across a wide range of organizations. The standard is also licensed under the Creative Commons “No Rights Reserved” license which means it is free to use.
Among all, the FHIR standard holds two major components, FHIR resources, and APIs. Before we dig into how FHIR data exchange is implemented, let’s start at the very beginning. What exactly are FHIR resources and FHIR API?
What is FHIR Resources?
Resources are instance-level representations of healthcare entities – a collection of information models that define the data elements, constraints, and relationships for “business objects” that are relevant to healthcare such as Patient, Procedure, Encounter, Observation, Order, etc. There are currently 145 defined Resources and over 50 more “proposed/expected” to be built listed on the FHIR website.
All Resources have these five features in common:
- A URL that identifies the Resource (example https://example.com/path/Patient/98635402)
- Common metadata (includes Logical ID [such as Patient ID] explicitly represented in the URL, version ID, and last modified date.)
- A human-readable XHTML summary
- A set of defined data elements – a different set for each type of Resource
- An extensibility framework to support variation in healthcare
Each Resource type defined in FHIR has a manager (or “entity set”) that lives at the address [FHIR Server]/[type]where the [type] is the name of the Resource type. For instance, the Resource Manager for the type Patient will live at https://server/path/Patient.
Each Resource instance also carries a human-readable text representation using HTML as an alternative contingency display option for clinical safety. This is often used for complex clinical information where existing systems currently use simple textual/document-based approaches.
Extending and restricting Resources (collectively known as ‘profiling a Resource’) is done with a “Structure Definition” Resource, which is a statement of rules about where extensions are used and/or how the data elements in a Resource are used.
For those of you less familiar with information models and data structures it might help to visualize each Resource as one of 145 single spreadsheets (Patient, Observation, Encounter, etc. tabs at the bottom) in a spreadsheet file (perhaps Resources.xslx) where the data fields like Name, Gender, Birthdate, Patient Identifier, etc. are columns for the Patient spreadsheet. Each Resource has different data and relationships so the columns for each Resource would be different.
What is FHIR API?
By definition, an API (Application Program Interface) is a collection of well-defined interfaces for interoperating between two applications. Although not required (implementers can also use GraphQL), the FHIR specification targets RESTful interfaces for API implementation. For manipulation of Resources, FHIR provides a REST API with a rich but simple set of Instance, Type, and System interactions that include:
- Create – Create a new Resource with a server assigned id = POST https://example.com/path/{resourceType}
- Read – Read the current state of the Resource = GET https://example.com/path/{resourceType}/{id}
- Update – Update an existing Resource by its id (or create it if it is new) = PUT https://example.com/path/{resourceType}/{id}
- Delete – Delete a Resource = DELETE https://example.com/path/{resourceType}/{id}
- Search – Search the Resource type or all Resources based on some filter criteria = GET https://example.com/path/{resourceType}?search parameters
- History – Retrieve the change history for a particular Resource or all Resources = GET https://example.com/path/{resourceType}/{id}/history
There are also more comprehensive interactions that include Batch/Transaction, Operation, Vread, Patch, and Capabilities. In addition to these interactions, there is an operations framework, which includes endpoints for validation, messaging, and documents.
Extending and Restricting the API – defining a set of desired behaviors – is done via the Capability Statement Resource which lists the REST interactions (read, update, search, etc.) that a server provides or that a client uses, along with some supporting information for each. The only interaction that servers are required to support is the Capabilities interaction itself – to retrieve the server’s Capability Statement.
Beyond that, servers and clients support and use whichever API calls are relevant to their specific use case. FHIR servers can also provide additional operations that are not part of the FHIR specification. The Conformance Resource supports defining what Operation Definitions make use of particular names on an endpoint.
Summary
FHIR has emerged to be a secure data standard for achieving true healthcare interoperability in recent times. The healthcare organizations, who early adopt FHIR will be able to achieve tremendous practice growth.
Getting Started With CapMinds FHIR Services
CapMinds is here to offer the best HL7 FHIR integration services for your practice in a faster and safer manner. Our expert team will strive to improve your healthcare organization’s productivity by simplifying day-to-day operations.
