Also would prefer this to follow NRLS and also include DocumentReference.class/specialty (this can be inferred from ReferralRequest but it saves processing if we don’t have to transform the DocumentReference). Specialty should be the same SNOMED valueSet as GPConnect and NRLS [care-setting-codes-snct-1] (would accept NHS Data Dictionary valueSet also).
In ReferralRequest would prefer the reference to Patient to be actual reference e.g. https://pds.proxy.nhs.uk/Patient/9409401122 rather than a reference to a contained resource [It makes reading the resource easier and makes it consistent with NRLS]
Would like examples to also be available in XML and the JSON to be formatted for human reading (prettyprint?)
Hi Kevin, sorry for the delay in replying, been coralling various views on this.
I think you have 3 specific points, which I’ll cover individually here:
Rationalisation of DocumentType between e-RS and NRLS
On this, the 2 values for the document type currently defined in the e-RS FHIR DocumentReference resource really indicate the origin of a document attached to the Referral (i.e. either Referrer or Provider). So, this is not in the spirit of the above. Although both DocumentReference resources do describe documents, they’re in quite different contexts, for NRLS it’s a nationally offered document / record. For e-RS it’s a document specifically related to the ‘parent’ referral.
Use of DocumentReference.class to identify the speciality which the Document is aligned to
The e-RS Specialties (and Clinic Types) are drawn from and aligned with the National Data Dictionary.
We could discuss (re)including the DocumentReference.class back into the e-RS specific DocumentReference profile (it exists in the parent ReferralRequest resource). Another option – if deemed necessary – might be to include a reference from the DocumentReference resource back to its parent (ReferralRequest) from where you could get the Specialty but circular references like this are generally not a great idea.
Rationalising the way that Patients are identified
For NRLS, we have predicted the future, and work on the assumption that at some point before NRLS is in production, a FHIR interface to PDS would exist. As such the URL is an imagined one, rather than anything else. e-RS has taken a slightly different approach and stayed within the bounds of the currently possible, hence the contained Patient resources. At the moment, there is no right answer to how we do this, though I’m hoping a resolvable URI becomes possible, if that were the case, there’s no reason for e-RS to not align. If a resovable URI doesn’t transpire, the approach we’ve proposed for NRLS will need to be reconsidered.
Hope these make sense, happy to discuss further either here or separately.
Specialties is looking like a mandatory field on our internal system (for DocumentReference). Most EDMS have stored documents in department folders which map easily to specialty. The EDMS and document sources we’ve looked at only have a limited amount of types, so not as useful for searching as class(specialty) would be. [Our EPR does have the full range of document types though].
For eRS we will be posting the documents to our Document Repository and will be taking the specialty from ReferralRequest (we need it to store the document in the correct folder). We’ve no preference on SNOMED or NHS Data Dictionary values for specialty, just want one system (I’m edging towards SNOMED as it’s quite powerful when used with a terminology server).