One of the core 'tenets' of FHIR is that the resources are deliberately kept simple, but that there is a built in mechanism to allow them to be adjusted to meet a particular Use Case. At the level of the individual resource, this is done by:

• Defining extra properties for a resource - called extensions. For example, a Condition does not (at the time of writing) have a property for acuity (whether a condition is acute or chronic). If we wanted to record this, we'd define an extension to do so.
• Constraining existing resource properties. For example we might want to indicate that a particular property is never used in out Use Case - for example we don't support Patient.photo, or that Patient.identifier is required, single and must come from a specific Code System

(There is more that you can do, but the above is likely to be the more common ones)

Then, you can take the individual 'profiles' of resources, and bundle them into an Implementation Guide, that consists of a number of different profiled resources and supporting documentation. 

There are a number of different resources in FHIR to support this.

The StructureDefinition resource is the one that actually defines what are the elements within a single resource. In fact, all of the FHIR resources are defined using this resource (called 'eating your own dog food' by some!) This resource is also used to define extensions as well as the resource - as they share the same characteristics).

• The ValueSet resource is used to define the possible options for a coded element (of datatype code, coding or CodeableConcept)
• The Composition and Bundle resources are then used to create the implementation package.

clinFHIR is capable of creating simple resource profiles - including extensions - to illustrate how this process works.