Part of the problem is that requirements behind why particular items make it into final specifications are not often reported in the specifications themselves (SDO's and PEO's take note, traceability from requirements to specifications is important). So understanding why patient identifiers are present in the metadata is important to coming up with a solution. As best as I can reconstruct from my own knowledge, here are the functions of these metadata elements:
|XDS Metadata Element||XDS||XDR||XDM|
|patientId||Identifies the patient whose information is being shared to the XDS registry that recieves it. Used to ensure the data is put with the right records.||Used to identify the patient whose information is being shared to the reciever. May be ignored by the reciever. It could be the recievers patient identifier when known in advance.|
|sourcePatientId||Identifies the patient whose information is being shared from the perspective of the sender of that data. Used to enable audit trails and diagnostics.|
|sourcePatientInfo||Provides further confirmation of the the patient whose information is being shared from the perspective of the sender of that data. Used to enable diagnostics.|
Given that this is reconstructed from memory, and because my memory is incomplete, I invite your comments on these details.
The problem is that simple message coming from e-mail, containing a CCD or CCR, may want to be routed through a gateway that translates it into XDM or XDR metadata. You can get just about everything you need from the "routing metadata" used by NHIN Direct. That metadata includes: from, to, date, and message id.
Submitter = From
IntendedRecipient = To
submission date / time = message date
message id can be tracably mapped to a submission identifier
hash, size and mimeType can be computed from the content.
typeCode and classCode can be set to generic values indicating "clinical data", or for certain types of documents (e.g., CCD or CCR), can be determined by inspection.
Author can be determined by inspection of some content, and can be assumed to be "From" for others (just plain text), but would have to be omitted elsewhere, and that's ok, because it's only required if it is known.
confidentialityCode could be slugged to a fixed value established according to policy by the gateway.
creationTime can be determined by inspection for CCD or CCR, but not for some other formats. It could use message date as a proxy.
sourcePatientInfo can be determined based on inspection of CCD or CCR documents, but not other formats, and is optional in the metadata.
But patientId and sourcePatientId are required, and can be obtained by inspection of only some formats. So what can be done for those?
Based on the intention for these fields, when using XDR and/or XDM, they could be based on any thing that uniquely identifies the patient, and both could contain the same value.
There are several possible solutions, but the one that I would propose is the following:
When the patient and message have a one to one relationship (message is about only one patient, which is the usual case), the message id provides a source of unique identity. This has the benefit of not being a Medical Record Number and possibly not being individual identifiable information. According to the Internet Message Format, the message id must be unique, and there are a couple of ways to make that identifier map into the appropriate XCN data type. One of these is to assign an OID used to identify patients by these message identifiers.
Of course, none of this is necessary when the content contains an XDM format zip file, because that will already have all of the necessary metadata in it.