1. Brief Profile Proposal for 2009/10 presented to the IT Infrastructure Planning Committee

2. IT Infrastructure Planning Committee The Problem Current XDS Metadata requires a set of metadata that is appropriate for XDS Document Registries but is not possible to generate in all XDR and XDM cases, particularly when the document source is not an EHR or equivalent (see use case)Current XDS Metadata requires a set of metadata that is appropriate for XDS Document Registries but is not possible to generate in all XDR and XDM cases, particularly when the document source is not an EHR or equivalent (see use case) In some case (motivated by Nationwide Health Information Network Direct Project use cases) the XDR/XDM packager is working with documents expressed as a byte stream, and must create a metadata package.In some case (motivated by Nationwide Health Information Network Direct Project use cases) the XDR/XDM packager is working with documents expressed as a byte stream, and must create a metadata package. Failure to address this issue in this cycle will require the Direct Project to propose use of non-conformant metadata that is not on a standards track to make conformantFailure to address this issue in this cycle will require the Direct Project to propose use of non-conformant metadata that is not on a standards track to make conformant

3. IT Infrastructure Planning Committee The Problem (Document Metadata) AttributeDiscussion classCodeDepending on the code set chosen by sender and receiver, it may not be possible to safely default a classCode without examining the underlying document. confidentialtyCodeIt will never be safe to assume that a document is of normal confidentiality without examining the underlying document creationTimeThe original creation time of the document is not always inferable from, e.g. PDF documents (where associated metadata may be the time of the PDF generation, not the time the original paper document was created). formatCodeSee remarks for classCode healthcareFacility TypeCodeDepending on the code set chosen, often can be inferred by configuration from sender, but may not be safely inferable at runtime in all case. languageCodeIt will often not be safe to assume document language without examining the underlying content. patientIDIt will never be safe to generate a patient ID if one is not known. It may be possible to use a special assigning authority OID that only has transactional identifiers; such use, however, violated the expectations on this attribute practiceSettingCodeSee remarks for healthcareFacility. sourcePatientIdSee remarks for patientID typeCodeSee remarks for classCode

4. IT Infrastructure Planning Committee The Problem (Submission Set Metadata) AttributeDiscussion contentTypeCodeDepending on the code set chosen by sender and receiver, it may not be possible to safely default a contentTypeCode without examining the underlying package. patientIdIt will never be safe to generate a patient ID if one is not known. It may be possible to use a special assigning authority OID that only has transactional identifiers; such use, however, violated the expectations on this attribute

5. IT Infrastructure Planning Committee Use Case Dr. Smith is referring a patient to Dr. Jones. Dr. Smith’s referral coordinator uses her e-mail or web e- communication application to write a textual summary of the referral and attaches a set of PDF formatted scanned documents. Dr. Smith’s office does not use a complete EHR; the competition for this workflow is the Fax machine. The web application sends an XDR SOAP message to Dr. Jones’ system.Dr. Smith is referring a patient to Dr. Jones. Dr. Smith’s referral coordinator uses her e-mail or web e- communication application to write a textual summary of the referral and attaches a set of PDF formatted scanned documents. Dr. Smith’s office does not use a complete EHR; the competition for this workflow is the Fax machine. The web application sends an XDR SOAP message to Dr. Jones’ system.

6. IT Infrastructure Planning Committee Proposed Standards & Systems This proposal relates to XDS Metadata, which we recommend re-terming XD* Metadata (as it is used for other profiles as well)This proposal relates to XDS Metadata, which we recommend re-terming XD* Metadata (as it is used for other profiles as well) We recommend the creation of at least two levels of conformant metadataWe recommend the creation of at least two levels of conformant metadata –Current XDS metadata –Minimal metadata We foresee the need for other possible levels. E.g.We foresee the need for other possible levels. E.g. –PatientID exists, but other required metadata does not –Use of metadata to package data not associated with a single specific patient As currently specified, the use case is not achievable with conformant metadataAs currently specified, the use case is not achievable with conformant metadata

7. IT Infrastructure Planning Committee Discussion Level of effort is minimal, particularly if the suggestions of the Direct Project are used as a starting point:Level of effort is minimal, particularly if the suggestions of the Direct Project are used as a starting point: –http://nhindirect.org/XDD+Specification Arien Malec will serve as proposal editor:Arien Malec will serve as proposal editor: –Arien Malec –Arien.malec@nhindirect.org Arien.malec@nhindirect.org –(510) 761-6473 Other relevant commentsOther relevant comments