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?