60 likes | 220 Views
Content Types for 360x. 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
E N D
Content Types for 360x 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
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 47049-2 (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 47049-2 (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.
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 <renderMultiMedia> and <observationMedia> construct of CDA (see CDAR2 section 4.3.5.6) • 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 57133-1 (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 <observationMedia> 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