Steps towards FHIR adoption

This is a two part question. Part 1 describes an approach towards FHIR adoption, and part 2 is a question about to what extent FHIR needs to be adopted.

Part 1
Is the below a valid approach for migrating a legacy system to one that adheres to the FHIR standard.
Step 1 - Remodel the database structure one entity at a time towards FHIR’s resource specifications. Starting with the key resources such as Patient, Practitioner, and Organization.
Step 2 - Support the db remodelling with new REST operations as FHIR specifies for accessing, searching and manipulating these Resources
Step 3 - Iteratively apply step 1 and step 2 within commercial projects so any work towards FHIR compliance is commercially supported by customers of the business

Step 1 and Step 2 tackle Resources (db structure) and Operations (REST APIs) which in my understanding are key tenets of FHIR adoption. Step 3 ensures the work is being done in a comercially viable way.

Is this similar to how others have approached this problem?

Part 2
When it comes to interoperability - does the FHIR standard exist as an API spec or a guide from which different API specs can be built?

For instance, if certain resources or resource attributes do not help solve a problem in the domain that a healthcare company operates in, it makes sense that it does not need to build support for that resource or those resource attributes. Is this allowed under FHIR? As long as each FHIR compliant company has a spec which specifies their level of FHIR adherence, it seems to me reasonable that not all resources need to be modelled nor all operations need to be supported.

What are your thoughts on this?

Part 1

that’s a valid approach, though most legacy systems remodel the database only reluctantly, if at all. - they have how their system works, and the FHIR API is just an expression of how the system already works

Part 2

The only part of the REST Api that has to be implemented is the CapabilityStatement fetch on /metadata. Anything else is optional, based on what the system does. There are many implementation guides that specify a subset of FHIR for a particular use case (e.g. see It’s better to implement one of those rather than your own custom one (of course, the real world is a compromise)