General issue for feedback from DDC on 15/12

[wweatherill-answer]

• [x] Drop eTag on Provider update and delete to simplify API until we know that we need it

• [x] Add date range filtering to search endpoint - this will be on the created date of the DocRef. Note that if a DocRef points to a dynamic record then the created date will be blank. In this instance those kinds of Pointers should be returned regardless of the date range search param - moved to ticket #34

• [x] The fact that type needs to be constrained needs calling out on the Add and Update endpoint. What kind of error should we return if the type is "invalid"

• [x] Define our audit requirements - local user, the system they're accessing through, their organisation, the query they sent and the Pointers that were returned in the result set. A lot of this info will be carried in the JWT - there is an open ticket for this here

• [x] Request that DDC change the name of SSP-from etc to something more generic like from-asid - this has now been raised as a separate ticket #33

[wilkinsm]

Should the created date be used and treated as a date range, i.e. allow the inclusion of multiple (possibly limited to 2) 'created' parameters, which define lower and upper boundaries?

Or should it be an exact match, within a date's implicit range?

My assumption here is the former.

[swk003]

Not sure I fully understand the Q. Are you suggesting that we extend the profile to support pointer date ranges? My understanding is that at the v least the DDC expect us to mimic the POC date range search param capability in the current API. So I would have thought (for now) we just need to include example searches with simple date range params (using prefixes) encoded in the URL.

[wilkinsm]

No suggestion of profile changes. Just looking for clarification on what should be allowed when a consumer/provider includes the created date as a search parameter.

I've now been through and looked at the Draft spec as I was not familiar with it. This has the created date range examples as you mentioned that needs to be replicated here. I can just follow these examples.

[swk003]

ok with you. Lets go with that for now.

[wilkinsm]

With regards to the 'Type' comment:

When the Type element is missing I would expect and error of INVALID_RESOURCE.

When the Type exists but is 'invalid', given that it is a 'preferred' codeableconcept I would expect either INVALID_CODE_SYSTEM or INVALID_CODE_VALUE, or possibly INVALID_VALUE.

These assumptions need verifying.

[swk003]

From conformance perspective we should ideally make the binding 'required'. This needs wider consensus which we haven't had to date.

[wilkinsm]

Discussions with Will has highlighted that the current binding and codes may not be adequately defined for this purpose. The codeable concept needs to be one of http://snomed.info/sct but within that we need to ensure we define an adequate subset.

The data model page will also require updates to reflect the decisions taken.

The assumptions around 'Type' errors mentioned above now stands, bar the mention of INVALID_VALUE.

[wilkinsm]

With regards to paging - it has been suggested that in the future the '_sort' parameter could of use. For now though it's inclusion may result in additional complexity we cannot afford in this release version.

[swk003]

The DocRef Type element (CodeableConcept) binding has been a known issue from the outset. Type currently binds to Care Plan Type subset (SNOMED) with specified example value: 'Mental health care plan (record artifact)'. We are waiting for the requirements to catch up with the spec before we can tighten this up.

[wilkinsm]

This ticket now only relates to e-tag, type, and paging as described above. Changes of which have now been reviewed and we can close this ticket.