Comments on:
http://data.developer.nhs.uk/fhir/nrls-v1-draft-a/Profile.RecordLocator/nrls-documentreference-1-0.html
The interaction model looks fine for the purpose.
There look to be some problems to be resolved around access rights e.g. can an organisation DELETE a record added by someone else? Also around sharing (especially wrt sensitivity) e.g. what happens if the record was recorded in a prison hospital/sexual health clinic/abortion clinic etc.
Dynamic endpoints
The model is tied to a document-centric model (i.e. XDS). The direction of travel is towards having computable, dynamic endpoints (e.g. GP Connect); it would be a shame if NRLS didnāt support that capability! I think that the gap is small and there is opportunity to cater for this.
content.attachment.size is mandatory. It might be unknown or change depending on details of the request.
Service discovery is a universal problem - has anyone spoken to the FHIR core team about this requirement?
Conformance
Great to see a conformance resource being published!
Iām not sure what the read Conformance operation on the server is for. The conformance resource for the server would normally be published on the / or /metadata routes [https://www.hl7.org/fhir/http.html#conformance]
Business identifiers vs logical identifiers
There is a pattern being used in the spec where business identifiers are being used as logical identifiers, for example:
https://sds.proxy.nhs.uk/Organization/A83627
https://pds.proxy.nhs.uk/Patient/9409401122
This is potentially dangerous as it mixes business identifiers with logical identifiers. The implementation guidance does make this distinction. This could create problems when consumers are pointing to multiple systems:
For example, we can retrieve a Patient from PDS:
GET https://pds.proxy.nhs.uk/Patient/9409401122
{
id: '9409401122'
resourceType: 'Patient'
}
then retrieve the same patient from a GP system:
GET https://gpconnect.proxy.nhs.uk/Patient/9409401122
{
id: '9409401122'
resourceType: 'Patient'
}
This creates a number of problems:
- as the resources now have the same logical identifier, the consumer canāt distinguish them! They are no longer 2 different records about the same business entity; they are 2 versions of the same record.
- it will create confusion for application developers about the difference between logical identity and business identity. They are likely to start using the business identifiers to short-circuit lookups, but this isnāt a universal pattern, which adds unnecessary complexity.
- it limits the ecosystem to records attached to verified NHS Numbers. What happens if the patient is registered in England and Wales, but has an episode of emergency care in Scotland, or used to reside in Australia?
I would strongly recommend looking at alternatives to this pattern! If you havenāt see it already, there is ongoing discussion about how identifiers should be represented within references:
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10659
Alternatively, if the proposal is that the request:
GET https://gpconnect.proxy.nhs.uk/Patient/9409401122
returns:
{
id: '54698721165467132132322'
resourceType: 'Patient',
identifier: [
{
system: 'nhsnumber',
value: '9409401122'
}
]
}
then the service wonāt be behaving according to the specification and conventions of FHIR, which will have itās own set of problems!
There is a knock-on effect in the search terms that need to be published.
For what itās worth, the query string approach works for me for most cases (e.g. 
I find it useful to remind myself that the purpose of the identity in /Patient/[identity] is to identify a single record about the patient, not to point to the Patient.