Assumptions The base use case is a referral initiated by the PCP, and a response sent back by a specialist The minimal payload requirement is a CCDA structured document, conforming to MU2 requirements – Best document type match for the referral is the CCD (CCDA, section 3.1) – Best document type match for the response is either the Discharge Summary if the patient was hospitalized (CCDA, section 3.4) or a Consultation Note (CCDA, section 3.2) The goal is to arrive at a guidance which will enable a relatively simple and quick implementation and a consistent path forward, allowing for gradually increasing the complexity of what can be communicated between systems A starting set of content types for the discussion are text/plain for messaging content, and images with content types of application/pdf, or image/jpeg Avoid overloading transport structures with semantic content The input to the STA is an RFC 5322 MIME message 0 Content Types for 360x

Discussion point 1 – messaging content If a referral is initiated, or responded to via a messaging system (as opposed to, for example, an ordering module) there is a possibility that the sender and/or recipient will type in a message, related to the referral/consultation. – If building the RFC 5322 MIME message directly, the messaging content is its own part, with a unique ID, and content-type of text/plain – If building the RFC 5322 MIME message directly, the messaging content is text/plain embedded in CCDA Unstructured Document (CCDA section 3.9), with LOINC document code of (Communication) – If using the DIRECT-recommended XDM structure (or the XDR edge protocol), the metadata for the document object representing the messaging content shall contain a LOINC typeCode of (Communication), and the mime type of the document object shall be either text/plain, or text/xml if the messaging content is embedded in CCDA Unstructured Document. Alternatively, no messaging content shall be allowed. 1 Content Types for 360x

Discussion point 2 – “BLOB” content types Non-structured content, providing supplemental information for the referral, or the response. – Loosely coupled with the minimal structured payload If building the RFC 5322 MIME message directly, the BLOB content is its own part, with a unique ID, and content-type of application/pdf or image/jpeg If using the DIRECT-recommended XDM structure (or the XDR edge protocol), the metadata for the submission set should contain both the document object for the CCDA payload, and the document object for the BLOB content. – Intended to be rendered as part of the clinical summary document, using the and construct of CDA (see CDAR2 section ) Embedded in the document (Base64 encoded) Referencing outside objects – same considerations as for loosely coupled BLOBs Alternatively, no BLOB content shall be allowed.

Content Types for 360x Discussion point 3 – other structured content types Other structured content may include a referral order with various administrative data, DICOM structured reports (DICOM SR), claims/eligibility data, etc. No standards have been considered for those, therefore no content types are for consideration, and the discussion from points 1 and 2 is most likely sufficient at this time

Content Types for 360x Derivations from the discussion points Sending multiple objects for a referral, or for the response – Using only the RFC 5322 MIME message structure will result in multiple MIME parts, each with unique ContentID, grouped by the message ID. – Using the DIRECT-recommended XDM packaging, any number of objects will still result in one MIME part, the XDM package. Within the XDM package each object will have unique ID, grouped by the submission set, and its unique ID. An important difference here is that the submission set can group objects across messages, allowing for size limits (10 MB) to be easily implementable even for future complex payloads Identifying the message as a referral – The CCDA implementation guide does not contain a specific document type for a referral content. Using the DIRECT-recommended XDM packaging allows for the classCode of the document object describing the CCD document, and/or the contentTypeCode of the submission set to specify LOINC code (Referral Note) as an indication that the message is a referral. Format of unique IDs – The CCDA implementation guide requires the unique document ID to be an OID. – The XDM package metadata also uses OIDs as the unique IDs representing the submission set and document objects – The MIME multipart specification has no specific formatting requirements for message ID and content ID, except uniqueness – There is a trivial UUID representation as OID – OIDs can be used in the construct of CDA as references (in urn format)

Content Types for 360x References Referenced specifications – (CCDA) Consolidated CDA Implementation Guide, Release 1.1, July 2012 – (CDAR2) Clinical Documentation Architecture, release 2, April 21, 2005