The GOMS already makes use of what the French Sante Core refers to as Business Identifier around the use of NHSNumber, ODSCode, GMP/GMP Numbers, etc.
The business identifiers (Resource.identifier), which can be multiple, make it possible to identify the resource outside the server.
It is advisable to favor the use of business identifiers to facilitate the identification of the resource outside the server.
I believe we may have a similar concept around codes, in particular ServiceRequest.reason.
In HL7 v2 (and so our FHIR) this is a CWE(/ FHIR CodeableConcept), a business code/value.
Also within the NW region we have many FHIR Servers (and Health Information Exchange (HIE) or Cross Enterprise Document Sharing (XDS/MHD) which will be the master detail record of the Condition.
(Nationally the equivalent is National Record Locator Service or Connecting Care Records).
So we may have references to this ‘bounded context’ (https://martinfowler.com/bliki/BoundedContext.html) or put another Technical Identifiers. So this is leaning me towards the following suggestion:
ServiceRequest.reasonReference is the Technical Identifier (and so no resource in the genomic test order bundle - it would be a duplicate to the actual resource)
ServiceRequest.reasonCode is the Business Code and can be used to retrieve the Condition.
We will need to take this internally to discuss. Regarding the technical identifier in reasonReference, the difference between Condition and the identifiers surrounding NHS Number and ODS code etc. are that the latter are ‘identifiers’ which have been agreed at a national level, and the resources behind them are served through national services. Conditions, on the other hand, are not stored centrally (at the moment) so there is no guarantee that references to conditions stored outside of GOMS are queryable. Additionally, querying via NRL/ConCR essentially entails retrieving documents (of potentially any type) so there is no guarantee that the necessary information for interpretation is included within those documents.
Regarding recording reasonCode in isolation, this is not sufficient for Genomic testing as data surrounding the condition needs to be populated to support interpretation, for example the clinical/verification status or the onset date, which is not provided through a condition code by itself.
The above may change with the advent of the UGR (Unified Genomic Record) or PDM, but you should consider the current reference to a Condition Resource and submission of this to the GOMS a tactical solution until these are in place, and GOMS integration into these services is confirmed.
I’ll seek other views but I that is moving the issue and making external systems (probably the trust TIE’s) having to implement clinical record queries instead.