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
- classCode
- confidentialityCode
- creationTime
- formatCode
- healthcareFacilityTypeCode
- languageCode
- patientId
- practiceSettingCode
- sourcePatientId
- typeCode
- Submission Set Metadata
- author
- contentTypeCode
- patientId
IHE Liked it!!!
IHE looked at this evaluation and ACCEPTED ALL and downgraded even MORE
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.
IHE looked at this evaluation and ACCEPTED ALL and downgraded even MORE
- Document Entry Metadata
- author
- Folder
- codeList
- patientId
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.
And for XDR they could have called upon the “Metadata-Limited Document Source” actor.
Even if they don’t like calling upon IHE specifications they could have just called on section 6 of the XDR and XDM for Direct Messaging specification
I hope that this is what Transport (b) means
I agree. Moreover It is really hard to understand the audit trails architecture in the DIRECT specifications. The specs say that auditing is up to the HIEs or outsourced HISPs, but there is no information on the content (i.e., they miss the ATNA reference). Were audits deliberately chosen to leave them out because of legacy software?
ReplyDeleteThe Direct Project put much of things out of scope, which is not unusual. Their focus was purely on a PUSH solution that was the most simple to deploy as a replacement for the FAX. They put Privacy Consent handling out-of-scope along with things like audit-logging. Indeed most IHE profiles don't mandate Audit Logging either, they describe the ATNA audit mapping, but the grouping is a system choice. The exception is XD* which I still don't like the mandate, but it was needed to move the industry.
Delete