search

nhsconnect / gpconnect

GP Connect API specification
https://digital.nhs.uk/services/gp-connect/gp-connect-specifications-for-developers
Apache License 2.0
34 stars 26 forks source link

Appointment Management - the storing and returning of Cosnumer entered information #304

Closed AndrewGuiseley closed 7 years ago

AndrewGuiseley commented 7 years ago

Guidance needs to be issued on GitHub with regards to consumer sent information as to how this is both stored in the Provider system and returned in the resource back to the Consumer

Examples include appointment reason and description

Explicit statement needs to be added about storing all the information such that is is available when the appointment is subsequently viewed/retrieved

briandiggle commented 7 years ago

description is covered by statement: provider systems...SHALL return an Appointment resource that conform to the gpconnect-appointment-1 profile.

reason is 0..* in gpconnect-appointment-1 - the suggestion is to add a Must-Support flag:

Where a Must-Support flag is present on a resource element, a consumer system SHALL populate the field in the request body if data is available to do so, irrespective of the fact that field cardinality may be 0..1 or 0..*.

Currently guidance in develop branch fits this: Similarly, provider systems SHALL populate an element in responses where data is available to do so, irrespective of optional cardinality. When a provider system receives data from a consumer for a field marked with the Must-Support flag, the provider system SHALL store this data field in such a way that the data element is preserved and the element can be populated in future responses to consumer requests for the resource in question.

james-answer commented 7 years ago

The description was made mandatory because some providers indicated that they do not support both description and comment, to stop ambiguity we made the description mandatory so consumers had atleast a consistent place in the message to look for some description text.

If we add a must support to the comment and reason elements we are not accepting that providers can not support the element and we are saying that they must store it so they can populate the element on a read of the appointment. The intention was not to make providers change what data they store unless our position has changed and we think the information that could be passed in the comment or reason is important and must be stored.

We could suggest that the providers store the information in another field such as adding the comment to the description but it will not come back on a read in the same field so it is not the same as adding a Must Support flag.