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.
"Metadata" that can be "obtained by inspection" of the content of the sent file isn't really metadata, is it?! Did I understand correctly from the XDR spec that a patient's name is "metadata"? Does this really not bother anyone else? I suppose it isn't as bad as requiring html within an xml document.
ReplyDeleteThe NHIN-Direct project has given us the opportunity to step back from legacy technologies and consider a greenfield solution to allow physicians to actually talk to each other for the benefit of their patients. It has also proven that the HIT community is shackled to its bloated legacy constructs and has become incapable of admitting its missteps or daring to think outside the box. We wouldn't want to lower market entry barriers and put pressure on the incumbent vendors to actually deliver value in a truly competitive market, would we? I'm just thankful that we have seen the user cost of HIT solutions significantly decrease over the past 5 years. (Oops)
The Scooter Guy
@Scooter Guy,
ReplyDeleteThe Patient's name is OPTIONAL metadata. The metadata field is there because many documents now days are not coded (PDF), and therefore it is 'nice to have' a well known metadata value that when two parties agree it is appropriate to use, that they have available to use.
I'm a little confused by Keith talking about an OID and John talking about the Patient's name. Keith, are you proposing only an OID (doesn't seem to be "simple..." for a patient? I realize that a name isn't a guaranteed unique identifier by any means, but for simple referrals, it is probably not far off.
ReplyDeletemod_doc, can we talk about the issues and not impugn or assume sinister motives, please?
I sincerely want to know, and I'm sure Keith and John and Scooter do too, the simple but profound question of how a patient is identified. If it is not in metadata (which wraps around the content), then it comes from the text by some sort of visual inspection (and maybe can be automatically extracted if the format was standardized, but standardizing formats is basically what metadata is about, without messing with the contents of the message or document itself.
Maybe visual inspection of a note, such as "Hi Joe, here's my note about the patient, John Doe, whom I'm sending to you" is enough -- it is similar to FAX, and that's not all bad. But as volumes increase, it would be good for provider productivity to be able to automate this. After all, when lab results come back to EHRs from Lab systems, you don't want a person having to sit in the middle manually deciding where to file everything. At least I hope we don't want to settle for that. We want to help clinicians communicate, but also want to keep costs down by letting computers do what they do best, and humans do what they do best.
David:
ReplyDeleteThe required components are the patientId and sourcePatientId. Other patient demographics can be carried in sourcePatientInfo.
John was responding to Scooter's comment on the fact that the patient name was metadata.
I was discussing how to deal with the required metadata.
thanks for posting this at the NHIN direct groups.
ReplyDeleteThoughts - Lab: Doesn't that work pt identification info and ORDERING DOC - so lab of record is going into a smaller pool for reconciliation.
In terms of patient name as identifier - privacy vs hassle vs issue of machine reconciliation - Right now a fax comes in the office for a referral & someone at the front desk reviews - either waits for the patient to call / come in or reaches out for an appointment OR ties the referral form to an arranged appointment that came by phone (or other note) - in short - patient is known or not in the Receiving office system (EHR or Practice Mgmnt). If known, file; if unknown - create patient and file. Either way...
What if we accept in NHIN direct a simple system that works at least as well as current processes, including without EHR / HIE exchange -- In this case - the Emerging and Legacy EHRs that handle the following will float to the top & users with nothing more than a fax or e-mail like client can meaningfully participate:
Key function for client - Simple Message File Function - that allows simple patient creation - as part of filing workflow.
John Haughton - DocSite
PS - not sure of protocol, I'll try to post at NHIN Direct as well.
I was just wondering what is the best way to determine the contenttype from metadata
ReplyDelete