What added value is there from Appointment.identifier, over Appointment.id?
Appointment.type.coding has example binding to SNOMED-CT, but this becomes a de facto required binding as coding.system is fixed. The underlying valueset is a) copyright (which creates potential licensing problems), b) requires mapping from existing coding systems.
The bound ValueSet does not map well to the use case (i.e. all appointments are 408443003 General medical practice) and can’t differentiate the range of appointments used within a GP practice (e.g. GP face to face consultation, Nurse well-person clinics, Flu vaccs drop in sessions, telephone consultations, home visits etc). Existing GP systems allow users to configure their own Slot types - how will these be reliably, robustly and usefully mapped to the bound ValueSet?
Appointment.reason.coding has required binding. FHIR ValueSet is currently required but (IIRC) will be preferred in future versions. FHIR ValueSet defines a presenting complaint (e.g. Abcess of hip). ‘CDA Encounter Type’ suggests a different intent (e.g. GP Consultation); ValueSet isn’t linked so I can’t check this.
Appointment.reason.coding is required. Presenting complaint may not be easily coded for GP use case. For example, patient does not provide reason to booking staff (‘Need to see GP - it’s personal’), patient has vague symptoms (‘feeling a bit funny this week’). Propose option to provide text only.