The scope of Metadata to support a short-term PUSH transactions is a bit more simple. Further even in a short-term PUSH transaction there can be a minimalistic viewpoint, actually 2 flavors of minimum. When IHE re-used the XDS transactions and metadata model for PUSH like transactions in XDM and XDR; there was not a critical review of the minimal metadata. For the most part we published the very same requirements and figured Public Comment or Trial Implementation would push-back if it was unreasonable. There was very little push-back. But in hindsight IHE needs to recognize that the audience at the time was mostly those with a XDS viewpoint, so there was not a critical view.
Along came the Direct project. Where there was a totally new audience, and as Wes is known for saying “Change the consensus group, change the consensus”. So, the Direct Project looked at the metadata requirements for IHE XDR, and downgraded some from mandatory to required-if-known. This is to some a huge change, but I really don’t see it as a big change. Most who would have seen a mandatory field and not having an answer would have either already sent it blank, or would have put static filler there. But, let’s look at the details.
What is Direct Minimal Metadata?You can get the full details from the XDR and XDM for Direct Messaging specification – Section 6.0 Here is the short version of the 13 metadata items Downgraded from Mandatory (R) to Required-If-Known (R2). The main reason is that this information is really not all that useful to a PUSH, it is more useful to a Query. The second reason is that this information is not typically found in an ambulatory or very low end clinic, or at least not in a highly structured and coded way.
Direct Downgraded from Mandatory (R) to Required-If-Known (R2)
- Document Entry Metadata
- Submission Set Metadata
IHE looked at this evaluation and ACCEPTED ALL and downgraded even MORE
- Document Entry Metadata
So why bother with metadata? The reason is that if the sender DOES know this information, it is useful to the recipient. Therefore if the sender has it, then it should be communicated (R2); and if it is useful to communicate that it should be communicated in an interoperable way. Given that these are just XML attributes, being empty or full doesn’t much matter. Remember the Transports are content agnostic, capable of carrying a CDA just as well as a PDF. This enables historic information, current information, and future formats we have not yet thought of. Content agnostic transport is a powerful thing, as is a reasonable set of metadata.
Additional Direct Special ConsiderationsIn order to code Direct Address elements in the metadata, extensions were defined for the author and intendedRecipient attributes. Tricks (Profiles) on how to make this happen in a reliable way. Again to assure best interoperability.
ConclusionIf ONC only wanted to specify that Minimal Metadata should be considered acceptable, they could have done that using the base XDM profile without modifications, which happen automatically to the already "Direct Project Applicability Statement" otherwise know as Transport (a). Meaning they already get minimal metadata with the base Direct specification, as the base XDM specification is already built into Direct.