There is no conformance statement to define the API capability. Which operations are available on which resources? Similarly, no description of the interactions within which these resources are used which limits ability to evaluate them. Hopefully this is being addressed in the forthcoming release.
In models, have the undocumented properties been constrained out (i.e. cardinality 0…0)? What about properties of base classes e.g. DomainResource, Resource
For resource reference resources it can be useful to provide *.display but not *.reference as this gives natural bound to data that can be retrieved by computational exploration.
The profiles may be useful elsewhere. Is the GPConnect-* naming convention going to act as a barrier to reuse?
A fair question and one that we are pondering on ourselves. There are many things that need to be named in “FHIR” including “profiles”, “System Ids”, “ValueSets” etc.
I will shortly be initiating a “project” through the Code4Health “Development” group to discuss how we can do this in a manner that allows appropriate levels of reuse.
Another point: There is a pattern in some of the profiles (e.g. Slot) where an explicit identifier has been documented e.g. ‘An identifier used to identify the slot’. I’m not clear what the intent is here. What added value is there from Slot.identifier, over Slot.id?