# National Record Locator Service specification **Category:** [FHIR](https://openhealthhub.org/c/fhir/31) **Created:** 2016-09-22 09:16 UTC **Views:** 3450 **Replies:** 17 **URL:** https://openhealthhub.org/t/national-record-locator-service-specification/633 --- ## Post #1 by @dunmail 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: 1. 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.:frowning2: 2. 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. 3. 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. --- ## Post #2 by @mayfield.g.kev Grahame Grieve was also asking for comments on logical identifiers http://www.healthintersections.com.au/?p=2557 (my comments are based on RLS). My preference would be to add an attribute which indicates it's a logical identifier. So ` ` becomes (using the NHSNumber system identifier and an attribute to indicate it's logical) ` ` or (implied logical using a query) ` ` I'd prefer to see **DocumentReference.class** added to the profile and use specialty. Every NHS Trust/Board I've worked with classifies documents with type and specialty. IHE UK also proposed doing the same for Document.class. We intend to reuse our facades we'd use for GPConnect (Patient and Organisation). Ideally we'd like to see the same security model (inc the use of JWT token). --- ## Post #3 by @mayfield.g.kev p.s. This thread has links to the SNOMED subsets referred to in the spec https://www.openhealthhub.org/t/uk-snomed-subsets-online-access/628/3 --- ## Post #4 by @TCoates Hi Dunmail, Kevin, thanks for the comments, I'm really glad to see people taking an interest! On your points (I think there were three key ones): 1) Authorisation: We've intentionally pushed that out to a separate responsibility. In our alpha implementation we've made some compromises, but in reality I see this all being controlled by proper oAuth2 based access control. Ideally we'll be able to grant granular access to each request based on a number of factors, including (of course) patient consent). Obviously there's quite a way to go to get to that, but I think we can safely say it shouldn't be solved by the record locator? 2) Dynamic endpoints: Agree, and I do worry that we're effectively baking in the document-centric paradigm. Hopefully we're not making any decisions which force us down that route, but I take the point that there are more mature approaches to sharing information. 3) Business vs Technical identifiers: Hands up, my bad! Early in the thinking I pushed for the use of 'obvious' and intuitive identifiers to be our approach, but I've since come to realise that this doesn't support what we really need to do. You provide some good scenarios, but for me the (admittedly edge case, but very real) issue of citizens with no NHS Number, or with two NHS Numbers, or who change NHS Number for some reason makes it absolutely clear that we should use only opaque technical identifiers. I'm now on a mission to convince others internally of this. I've seen the propsal to allow resources to be referenced by identifier rather than just by ID, and I really don't like it. I think that risks breaking one of the key strengths of FHIR, that resources should be resolvable. What do you do if you get a resource identified as: I think Graham's propsal said that it: “…allows a resource writer to write resources it otherwise couldn’t” I'd say that it: “…also allows a resource writer to write resources it **shouldn’t**” Tim --- ## Post #5 by @dunmail Hi Tim, Auth - absolutely agree that it isn't part of record locator and a central authn/authz service would be a massive change in how apps and services could work. Dynamic endpoints - I'll have a chat to the FHIR core team, as we (collectively) won't be the only people worrying about this. Identifiers - Cool. Let me know if any of your colleagues need further education :grinning: For what it's worth, the query string approach works for me for most cases (_e.g_. `Patient?identifier=nhs|9123456789`). I'm not convinced that unresolvable but computable references lie in the 80%. --- ## Post #6 by @mayfield.g.kev In our ESB (large hospital). We probably won't be providing direct access to spine proxy. Internally spine access would look like: http://spine.jorviktrust.nhs.uk. So we may have to change national references between trust ESB standard and NHSEngland - having logical references help minimise this. Our internal proxy/facade would allow us convert handle security mappings and conversion to and from DSTU2 and STU3 (which allows us to standardise on STU3). --- ## Post #7 by @TCoates :slight_smile: 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. --- ## Post #8 by @TCoates [quote="mayfield.g.kev, post:6, topic:633"] ould a [/quote] Wouldn't you just have http://spine.jorviktrust.nhs.uk/Patient/[Any old GUID] but then inside the Patient resource have multiple identifiers, one of which uses the formal PDS url (once defined) for system and the NHS Number for value, and then any other(s) as required using a similar structure to hold any local Unit / Hospital Numbers ? You can then identify that Patient record by the GUID: /Patient/GUID_VALUE_HERE Or by NHS Number: /Patient?identifier=http://pds.nhs.uk|1234567890 Or by local number /Patient?identifier=http://jorvik.nhs.uk|3456321 --- ## Post #9 by @mayfield.g.kev It's the DocumentReference POST to RLS that's behind my comments. If we're doing it the full way it would be a Bundle which included a Patient resource. [I prefer the shorthand way suggested in the RLS spec though]. What I mean by full is: using a Bundle which contains all the resources the DocumentReference refers to, as shown in this XDS sample http://hl7.org/fhir/2016Sep/xds-example.xml.html At my previous trust we'd have the NHS Number in the Patient.identifier section, so this query would work **/Patient?identifier=http://fhir.nhs.net/Id/nhs-number|9990001170**. This finds the trust's Patient that has that NHSNumber (we did the same for SMSP). We're at early stages of profiling Patient within the trust but it's very likely we'd do the same - using NHSDigital identifier for NHS Number. Which is why I'd be reluctant to use these references **https://pds.proxy.nhs.uk/Patient/9990001170** within the trust, it does not link to any identifiers used in the trust and doesn't point to a real system (directly accessible within the trust). --- ## Post #10 by @TCoates Totally agree that having a canonical resolvable URL for Patients (and other resources) is essential to us adopting FHIR. --- ## Post #11 by @dunmail One observation is that if we express references as a search: { ref: 'Patient?identifier=nhs|9123456789' } We can then resolve this on *any* FHIR server: `GET https://pds.nhs.uk/Patient?identifier=nhs|9123456789` `GET https://yorvik.nhs.uk/Patient?identifier=nhs|9123456789` `GET https://svc.blackpear.thirdparty.nhs.uk/Patient?identifier=nhs|9123456789` `GET https://spark.furore.com/Patient?identifier=nhs|9123456789` This feels like a powerful pattern, though isn't quite the intent of the relative reference in the FHIR spec. Is it a useful pattern? Cheers, Dunmail --- ## Post #12 by @mayfield.g.kev For RLS this would apply in several areas such as DocumentReference.subject (Patient identifier is NHS Number), DocumentReference.custodian.reference (Organisation identifier is ODS Code) and DocumentReference.author (Practitioner identifier is GMP/GMC code) All (NHS) consumers should be able to resolve the references. Also how we resolve national references is down to local business rules. Do we use pds.nhs.uk, our own reference to a patient, social services or community? The address and contact numbers in pds.nhs.uk may not be current. That would be very useful to us (acute trust). As you mention, It's not relative but the reference does imply you need to resolve the reference and it's a logical reference. --- ## Post #13 by @dunmail I've pushed this idea to the FHIR core team to explain why it's bad ... --- ## Post #14 by @mayfield.g.kev FYI I'm presuming the spine proxy service and the one in GP Connect are the same (or should be very similar). GP Connect demonstrator is using this to search in Patient by NHSNumber http://ec2-54-194-109-184.eu-west-1.compute.amazonaws.com/fhir/Patient?identifier=http://fhir.nhs.net/Id/nhs-number|9000000033 This returns the same Patient http://ec2-54-194-109-184.eu-west-1.compute.amazonaws.com/fhir/Patient/4 --- ## Post #15 by @TCoates The proxy service is just a notional recognition that we'd expect nationally mediated messaging (rather than expect everyone to allow connections from everywhere. There is going to be a challenge in making locally relative (not addressed via a proxy) references resolvable nationally (via a proxy) but it's unlikely to be insurmountable. For the initial tests we're not going to have resolvable patients (or organisations etc), so a lot of what's inferred is still to be defined. See also: http://developer.nhs.uk/library/systems/national-record-locator-service/ --- ## Post #16 by @mayfield.g.kev @dunmail what was the outcome? Tried several links and still confused. Last I got gleaned from http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10659 is the changes for logical references are for not for our use case - where we **should** be able to resolve a reference. --- ## Post #17 by @dunmail Spec has been changed on a trial basis with a review after 1 month. It doesn't yet feel like a clean solution to their use case yet. I think the conditional references may be what we need for our use case and it was agreed that it could be a useful pattern. --- ## Post #18 by @mayfield.g.kev On a related note. We're looking at using this lookup internally for EDMS stores and RLS. **$BaseURL + '/DocumentReference?patient.identifier=http://fhir.nhs.net/Id/nhs-number|'+$NHSNumber** This is different to RLS but it's a pretty straight forward conversion **$RLSURL + '/DocumentReference?subject=https://pds.proxy.nhs.uk/Patient/'+$NHSNumber** Both look correct to me and it's a just where the query is being made. NHSNumber being a logical identifier within the trust and an actual reference on the RLS call. We've used HAPI FHIR Server to simulate the RLS and it was quite easy to POST in the examples from RLS and then use that with a simple client. --- **Canonical:** https://openhealthhub.org/t/national-record-locator-service-specification/633 **Original content:** https://openhealthhub.org/t/national-record-locator-service-specification/633