ESMD FHIR Implementation Guide
1.0.0 - esmd

ESMD FHIR Implementation Guide - Local Development build (v1.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Bundle Submission Elements Inbound LO Bs

Section 1: esMD Functional Specifications Submission Set and Metadata Attributes for LOBs

The following table outlines the Functional Specifications Submission Set and Metadata Attributes for the following Lines of Business (LOBs) within the esMD system:

  1. Additional Documentation Request (ADR) (CTC 1) ADR submissions are used by Medicare Administrative Contractors (MACs) to request additional documentation from healthcare providers to support a claim. This metadata set ensures that the requested information is electronically submitted and accurately reflects the needs of the request.

  2. Recovery Audit Contractor (RAC) Discussion Request (CTC 11) RAC Discussion Requests are initiated when a provider wishes to discuss or appeal a finding made by a Recovery Audit Contractor, typically relating to claims or payment discrepancies. This submission set contains metadata that facilitates proper documentation exchange and discussion with the contractor.

  3. Durable Medical Equipment (DME) Phone Discussion Request (CTC 11.1) DME Phone Discussion Requests are specific to Durable Medical Equipment and provide a platform for providers to discuss issues or clarification with contractors regarding DME claims. This metadata includes submission attributes that allow for accurate record-keeping and response tracking during the phone discussion process.

Table 1

ID XDR METADATA ELEMENT FHIR ELEMENT/EXTENSION ELEMENT DESCRIPTION VALIDATION RULE LENGTH & FORMAT REQUIRED/OPTIONAL
1 Unique ID Esmd-Ext-UniqueId A globally unique identifier is assigned by the Health Information Handler (HIH) to each document within the Submission Set. This Unique ID is included in the response sent back to the HIH, ensuring consistent tracking and identification of each document throughout the submission process.
  • Invalid Length and Format of Unique ID
  • A Unique ID that exceeds 64 characters in length is considered invalid. The Unique ID should comply with the defined length constraints.
  • Duplicate Unique ID Each Unique ID must be unique within the system to maintain data integrity.
  • Length must be between 1 and 64 Characters
  • Format Must Be Alphanumeric
  • Can contain Dashes and Underscores
    		•  R
    2 Parent Unique ID Esmd-Ext-ParentUniqueId The Parent UniqueId is utilized by the esMD System to group multiple submission files into a single transaction when a Health Information Handler (HIH) needs to divide a large payload into multiple submissions. This Parent UniqueId serves as the unique identifier for the initial transaction, and it is included in all subsequent transactions related to the split payload. By using the Parent UniqueId, Review Contractors can efficiently combine and review all submissions associated with a single payload. This ensures a smooth processing experience while maintaining the integrity of the clinical documentation.
  • Parent Unique ID must be present if a split payload is sent.
  • Missing Parent Unique ID If a Split Number is present for multiple submissions, a Parent Unique ID must be provided. The absence of the Parent Unique ID in this scenario will be flagged as an error, as it is necessary to associate all split submissions with the initial transaction.
  • Length must be between 1 and 64 Characters
  • Format Must Be Alphanumeric
  • Can contain Dashes and Underscores and no other special characters are allowed.
    		•  R
    3 HIH OID Esmd-Ext-SenderOid Coding A Globally Unique Identifier (GUID), in OID (Object Identifier) format, is used to uniquely identify the Health Information Handler (HIH). This identifier ensures that the HIH can be distinctly recognized across systems, providing a consistent and reliable reference within the health information management process.
  • Invalid HIH OID
  • Missing HIH OID
  • Valid format check of HIH OID and CTC
  • Invalid combination of HIH OID and Content Type Code
    		•
  • Length must be between 1 to 64 Characters
  • Format must be as stated: "urn:oid:1.3.6.1.4.1.101420.6.1"
    		•  R
    4 RC OID Esmd-Ext-IntendedRecipient Coding The Intended Recipient refers to the organization (RC) that will receive the message from the sender (HIH) containing the esMD Claim supporting documents. This Intended Recipient will be uniquely identified using an OID (Object Identifier) issued by HL7.
  • Invalid RC OID
  • Missing RC OID
  • Valid format check of RC OID and CTC. 24 Invalid combination of RC OID and Content Type Code
    		•
  • Length must be between 1 to 64 Characters
  • Format must be as stated: "urn:oid:1.3.6.1.4.1.101420.6.1"
    		•  R
    5 Content Type Code/Line Of Business Id Esmd-Ext-LinesOfBusinessId The Content Type Code identifies the specific line of business for which the provider or Health Information Handler (HIH) is submitting the request.
  • Content Type Code or Line of Business ID must be part of esMD and in active status
  • Invalid Content Type Code
  • Content Type Code Missing
    		•
  • Length 1 -16
  • Format must be numeric with period Ex: "1 or 1.1or 11"
    		•  R
    6 NPI Esmd-Ext-NPI Represents the provider's NPI or institution's NPI that authored the individual document included in the Submission Set. Invalid NPI Missing NPI Missing String
  • Length must be 10 numeric.
  • Format or Example: 1234567890
    		•  R
    7 Claim ID Esmd-Ext-ClaimId The Claim Identifier is the identifier used by the provider to submit the medical claim to the esMD system. It can be submitted in either Standard or Composite Format.
  • Valid Claim ID Format Check The Claim ID must follow one of these valid formats: 8 Numeric Characters (must not be all zeroes). 13–15 Numeric Characters (must not be all zeroes). 17–23 Alphanumeric Characters, including hyphens, underscores, or spaces (must not be all spaces, all zeroes, or all a single special character).
  • Invalid Claim ID Format Check If the Claim ID does not meet any of the valid format criteria outlined above (e.g., containing invalid characters, incorrect length, or all zeroes), it is considered invalid.
  • Missing Claim ID or Empty Tag or Missing String If the Claim ID is missing, the tag is empty, or the string is absent, this should be flagged as an error due to the missing or empty Claim ID.
    		•
  • Claim ID length must be 1-23 character for either standard or composite format.
  • Claim ID in Standard Format: 8 numeric characters (must not be all zeroes) 13–15 numeric characters (must not be all zeroes) 17–23 alphanumeric characters, including hyphens, spaces, and underscores (must not be all spaces, all zeroes, or all a single special character). Composite Claim ID Format Ex: [Claim ID^^^&RC OID&ISO]
    		• R
    8 Case ID Esmd-Ext-CaseId The Case Identifier is generated by the Review Contractor (RC) to open a claim-specific case. The Case ID can be submitted in either Standard or Composite Format, depending on the requirements of the Line of Business (LOB).
  • Case ID if sent the format must be valid.
  • Invalid Case ID format
    		•
  • Case ID length must be 1-23 character for either standard or composite format.
  • Length must be 0–32 characters if it is optional.
  • Case ID can be sent in Composite format Ex: "CaseID^^^&RC OID&ISO"
  • Format check (No check is performed up to the "CaseID"; the only format check starts from the "^^^&RC OID&ISO")
    		•  O
    9 Comments - Notes Comments associated with the Submission Set are provided as free-form text. The Health Information Handler (HIH) or Provider may include additional details or clarifications when submitting the documentation, if necessary. No check any value sent in the string will be taken and processed. The max character limit is 256 in length. Length 0-256 characters O
    10 Submission Time FHIR Date Format The Submission Time refers to the specific point in time when the Bundle Submission Set was created by the Health Information Handler (HIH). Timestamp is required, and the system will ensure the following: Timestamp is present. Valid format as per FHIR standards (e.g., YYYY-MM-DDThh:mm:ss+zz:zz). Missing timestamp will trigger an error.
  • Timestamp Format Validation: The timestamp is validated to ensure it follows the correct format: YYYY-MM-DDThh:mm:ss+zz:zz Where: YYYY = Year MM = Month DD = Day hh = Hour mm = Minute ss = Second +zz:zz = Timezone offset
    		• R
    11 Split Number Esmd-Ext-SplitNumber The Split Number is used by the esMD system when a Health Information Handler (HIH) submits a large payload that needs to be divided into smaller parts for efficient submission and delivery. It uniquely identifies the sequence of each part in a series of split submissions. This ensures that all parts of the submission can be correctly combined and reviewed as a complete set by the receiving Review Contractor (RC). The Split Number helps maintain the order and integrity of the submission, streamlining the processing of large payloads across multiple transactions.
  • Invalid Split Number Format and Length If the Split Number does not adhere to the required format or exceeds the allowed length, it will be flagged as invalid.
  • Missing Split Number Sequence If a Split Number sequence is missing (i.e., if a part of the submission does not have a properly assigned sequence number), it will be considered an error and will prevent proper processing.
  • More Split Numbers Received Than Numbered If the number of Split Numbers received exceeds the expected sequence (e.g., more parts submitted than numbered in the sequence), it will be flagged as an error.
  • Duplicate Split Numbers Received in the Submission If any Split Numbers are duplicated within the submission, it will be identified as a duplicate and result in an error, as each Split Number must be unique within the transaction. Note: The Split Number is a required element when large payloads are sent in multiple splits within the same transaction. If there are multiple payloads, a Split Number must be provided, and the Parent Unique ID must also be present to ensure proper identification and sequencing of the split submissions.
  • Length Requirements The Split Number must have a minimum length of 3 characters and a maximum length of 5 characters.
  • Numeric with Dash The Split Number must be numeric and include a dash between the numbers.
  • Format Requirements The Split Number must follow the format: number-dash-number. For example: 1-1, 12-34, etc.
  • Maximum Split Submissions A maximum of 99 split submissions is allowed, meaning the highest acceptable Split Number is 99-99.
    		•  O
    13 Class Code category CodableConcept The name displayed to communicate the meaning of the classCode will have a single value for each classCode value, ensuring clear and consistent communication of its meaning to a human user. Valid Class Code Invalid or Missing Class Code Class code string must be present The Class Code must always be "1" for all the Content Type Codes/Line of Business IDs R
    14 Format code content.format Coding esMD FHIR supports the following types of clinical documents:
  • Unstructured clinical notes and scanned documents (HITSP C62).
  • Structured clinical summaries (HITSP C32). HITSP C32 provides detailed guidance for exchanging clinical summaries between different healthcare systems. The C32 specification defines the format for the Continuity of Care Document (CCD), which is used to share structured clinical data in a standardized way. esMD supports structured clinical summaries in Clinical XML format. If a clinical summary contains unstructured information, the embedded format must still be PDF, XML, or JSON. In this case, the appropriate format code should be applied based on the document's content and encoding.
    		• Valid Format Code Invalid or Missing Format Code Format code string must be present The esMD system has customized and created the following format codes are supported: PDF Document: Format Code: urn:ihe:iti:xds-sd:pdf:2008 Text Document: Format Code: urn:ihe:iti:xds:2017:mimeTypeSufficient R
    15 Health Care Facilitytype code context.facilityType CodableConcept The facility type code represents the type of organizational or provider setting in which the claim or clinical encounter occurred, or where the documented act took place. HL7 Facility Types: Instead of listing individual HL7 codes, the entire HL7 v3 RoleCode system () is referenced. This allows the ValueSet to include all HL7-defined facility types, such as hospitals, ambulatory care centers, skilled nursing facilities, and more. Valid Health Care Facility Type Code Invalid or Missing String or Empty HealthcareFacilityType code The esMD system has created custom Facility Types: hih: Health Information Handler hcp: Health Care Provider cms-rc: CMS Review Contractor These codes are defined in a custom code system, available at: . R
    16 Confidentiality Code securityLabel CodableConcept The confidentiality code specifies the level of confidentiality for each attached clinical document, indicating the sensitivity and access restrictions associated with the document. Valid Confidentiality Code Invalid or Missing code Empty Confidentiality Code string For the esMD, the value is always ‘V’: V- very restricted R
    17 Response Type Category Esmd-Ext-ResponseTypeCategory The Response Type Category identifies the different types of responses from Handlers (HIHs) or Providers. These responses have pre-determined values, which are decided by the Review Contractors (RCs), in addition to the Content Type Code (CTC). The Response Type Category element is optional and if submitted the system will do the length check only and ensures it does not exceed more than the defined length. Length 0-100 characters and no format check. O
    18 MIME type content.attachment.contentType code A MIME type (or media type) is a method of identifying file formats and content transmitted over the internet. MIME types allow browsers to recognize the file type of a file sent via HTTP by the web server. This enables the browser to select an appropriate method for displaying the content. Common MIME types include, for example: text/html for HTML files image/jpeg for JPEG image files Mime Type must be present. Invalid MIME type format Invalid length and format The MIME type must have a length between 1 and 64 characters. The format for Mime type must be "application/pdf" for PDF documents. Note: MIME type values are case-sensitive, so it must be entered exactly as "application/pdf". R
    19 Hash content.attachment.hash base64Binary A hash key is a value generated from a string of text in a way that is nearly impossible to turn back into the original text. In the context of your statement: The hash key of the XDR payload (C62 document attachment) is generated using the SHA-1 hash algorithm. This hash key is a unique identifier for the content, ensuring that any changes to the document will result in a different hash value, allowing for integrity verification of the document. The system will check the Hash element string is present, if submitted the system will do the length check only and ensures it does not exceed more than the defined length. The Length must be 1 to 256 characters only and no format check any characters are allowed. R
    20 Creation Time date Type is instant The creation date and time stamp is an element that represents the date and time when the Health Information Handler (HIH) created the document that is being processed by esMD. Creation Timestamp is required, and the system will ensure the following: Timestamp is present. Valid format as per FHIR standards (e.g., YYYY-MM-DDThh:mm:ss+zz:zz). Missing timestamp will trigger an error.
  • Timestamp Format Validation: The timestamp is validated to ensure it follows the correct format: YYYY-MM-DDThh:mm:ss+zz:zz Where: YYYY = Year MM = Month DD = Day hh = Hour mm = Minute ss = Second +zz:zz = Timezone offset
    		• R
    21 Language Code content.attachment.language The language code specifies the human language used for the character data in the document.
  • Valid Language Code
  • Invalid or Missing Language Code
    		•  The language code must always be "en-us". The length of the language code must be between 1 and 16 characters. R
    22 Document ID Id A Document ID is a unique identifier that must match between the ID inside the bundle metadata and the document ID assigned to the attached payload.
  • Missing Document ID
  • Invalid Document ID
  • Document ID in the metadata does not match with the document in the attached document
  • Payload successfully decoded for Document
    		•  The length must be between 1 and 256 characters. R

    Section 2: esMD Functional Specifications Submission Set and Metadata Attributes for LOBs

    The following table outlines the Functional Specifications Submission Set and Metadata Attributes for the following Lines of Business (LOBs) within the esMD system:

    1. First Level Appeal Requests (CTC 9) First Level Appeal Requests (CTC 9) are initiated by healthcare providers when they wish to appeal an adverse decision or claim denial by a Medicare contractor. This submission set facilitates the submission of documentation to support the appeal and ensures it is tracked in accordance with the esMD standards.

    2. Second Level Appeal Requests (CTC 9.1) Second Level Appeal Requests (CTC 9.1) are filed when the First Level Appeal has been denied, and the provider seeks further review of the decision. This submission set includes metadata attributes to ensure that the appeal documentation is appropriately processed and accurately reviewed at the second level.

    Table 2: First Level and Second Level Appeal Requests Elements

    ID XDR METADATA ELEMENT FHIR ELEMENT/EXTENSION ELEMENT DESCRIPTION VALIDATION RULE LENGTH & FORMAT REQUIRED/OPTIONAL
    1 Unique ID Esmd-Ext-UniqueId A globally unique identifier is assigned by the Health Information Handler (HIH) to each document within the Submission Set. This Unique ID is included in the response sent back to the HIH, ensuring consistent tracking and identification of each document throughout the submission process.
  • Invalid Length and Format of Unique ID
  • A Unique ID that exceeds 64 characters in length is considered invalid. The Unique ID should comply with the defined length constraints.
  • Duplicate Unique ID Each Unique ID must be unique within the system to maintain data integrity.
  • Length must be between 1 and 64 Characters
  • Format Must Be Alphanumeric
  • Can contain Dashes and Underscores
    		•  R
    2 Parent Unique ID Esmd-Ext-ParentUniqueId The Parent UniqueId is utilized by the esMD System to group multiple submission files into a single transaction when a Health Information Handler (HIH) needs to divide a large payload into multiple submissions. This Parent UniqueId serves as the unique identifier for the initial transaction, and it is included in all subsequent transactions related to the split payload. By using the Parent UniqueId, Review Contractors can efficiently combine and review all submissions associated with a single payload. This ensures a smooth processing experience while maintaining the integrity of the clinical documentation.
  • Parent Unique ID must be present if a split payload is sent.
  • Missing Parent Unique ID If a Split Number is present for multiple submissions, a Parent Unique ID must be provided. The absence of the Parent Unique ID in this scenario will be flagged as an error, as it is necessary to associate all split submissions with the initial transaction.
  • Length must be between 1 and 64 Characters
  • Format Must Be Alphanumeric
  • Can contain Dashes and Underscores and no other special characters are allowed.
    		•  R
    3 HIH OID Esmd-Ext-SenderOid Coding A Globally Unique Identifier (GUID), in OID (Object Identifier) format, is used to uniquely identify the Health Information Handler (HIH). This identifier ensures that the HIH can be distinctly recognized across systems, providing a consistent and reliable reference within the health information management process.
  • Invalid HIH OID
  • Missing HIH OID
  • Valid format check of HIH OID and CTC
  • Invalid combination of HIH OID and Content Type Code
    		•
  • Length must be between 1 to 64 Characters
  • Format must be as stated: "urn:oid:1.3.6.1.4.1.101420.6.1"
    		•  R
    4 RC OID Esmd-Ext-IntendedRecipient Coding The Intended Recipient refers to the organization (RC) that will receive the message from the sender (HIH) containing the esMD Claim supporting documents. This Intended Recipient will be uniquely identified using an OID (Object Identifier) issued by HL7.
  • Invalid RC OID
  • Missing RC OID
  • Valid format check of RC OID and CTC. 24 Invalid combination of RC OID and Content Type Code
    		•
  • Length must be between 1 to 64 Characters
  • Format must be as stated: "urn:oid:1.3.6.1.4.1.101420.6.1"
    		•  R
    5 Content Type Code/Line Of Business Id Esmd-Ext-LinesOfBusinessId The Content Type Code identifies the specific line of business for which the provider or Health Information Handler (HIH) is submitting the request.
  • Content Type Code or Line of Business ID must be part of esMD and in active status
  • Invalid Content Type Code
  • Content Type Code Missing
    		•
  • Length 1 -16
  • Format must be numeric with period Ex: "1 or 1.1or 11"
    		•  R
    6 NPI Esmd-Ext-NPI Represents the provider's NPI or institution's NPI that authored the individual document included in the Submission Set. Invalid NPI Missing NPI Missing String
  • Length must be 10 numeric.
  • Format or Example: 1234567890
    		•  R
    7 Claim ID Esmd-Ext-ClaimId The Claim Identifier is the identifier used by the provider to submit the medical claim to the esMD system. It can be submitted in either Standard or Composite Format.
  • Valid Claim ID Format Check The Claim ID must follow one of these valid formats: 8 Numeric Characters (must not be all zeroes). 13–15 Numeric Characters (must not be all zeroes). 17–23 Alphanumeric Characters, including hyphens, underscores, or spaces (must not be all spaces, all zeroes, or all a single special character).
  • Invalid Claim ID Format Check If the Claim ID does not meet any of the valid format criteria outlined above (e.g., containing invalid characters, incorrect length, or all zeroes), it is considered invalid.
  • Missing Claim ID or Empty Tag or Missing String If the Claim ID is missing, the tag is empty, or the string is absent, this should be flagged as an error due to the missing or empty Claim ID.
    		•
  • Claim ID length must be 1-23 character for either standard or composite format.
  • Claim ID in Standard Format: 8 numeric characters (must not be all zeroes) 13–15 numeric characters (must not be all zeroes) 17–23 alphanumeric characters, including hyphens, spaces, and underscores (must not be all spaces, all zeroes, or all a single special character). Composite Claim ID Format Ex: [Claim ID^^^&RC OID&ISO]
    		• O
    8 Case ID Esmd-Ext-CaseId The Case Identifier is generated by the Review Contractor (RC) to open a claim-specific case. The Case ID can be submitted in either Standard or Composite Format, depending on the requirements of the Line of Business (LOB).
  • Case ID if sent the format must be valid.
  • Invalid Case ID format
    		•
  • Case ID length must be 1-23 character for either standard or composite format.
  • Length must be 0–32 characters if it is optional.
  • Case ID can be sent in Composite format Ex: "CaseID^^^&RC OID&ISO"
  • Format check (No check is performed up to the "CaseID"; the only format check starts from the "^^^&RC OID&ISO")
    		•  O
    9 Comments - Notes Comments associated with the Submission Set are provided as free-form text. The Health Information Handler (HIH) or Provider may include additional details or clarifications when submitting the documentation, if necessary. No check any value sent in the string will be taken and processed. The max character limit is 256 in length. Length 0-256 characters O
    10 Submission Time FHIR Date Format The Submission Time refers to the specific point in time when the Bundle Submission Set was created by the Health Information Handler (HIH). Timestamp is required, and the system will ensure the following: Timestamp is present. Valid format as per FHIR standards (e.g., YYYY-MM-DDThh:mm:ss+zz:zz). Missing timestamp will trigger an error.
  • Timestamp Format Validation: The timestamp is validated to ensure it follows the correct format: YYYY-MM-DDThh:mm:ss+zz:zz Where: YYYY = Year MM = Month DD = Day hh = Hour mm = Minute ss = Second +zz:zz = Timezone offset
    		• R
    11 Split Number Esmd-Ext-SplitNumber The Split Number is used by the esMD system when a Health Information Handler (HIH) submits a large payload that needs to be divided into smaller parts for efficient submission and delivery. It uniquely identifies the sequence of each part in a series of split submissions. This ensures that all parts of the submission can be correctly combined and reviewed as a complete set by the receiving Review Contractor (RC). The Split Number helps maintain the order and integrity of the submission, streamlining the processing of large payloads across multiple transactions.
  • Invalid Split Number Format and Length If the Split Number does not adhere to the required format or exceeds the allowed length, it will be flagged as invalid.
  • Missing Split Number Sequence If a Split Number sequence is missing (i.e., if a part of the submission does not have a properly assigned sequence number), it will be considered an error and will prevent proper processing.
  • More Split Numbers Received Than Numbered If the number of Split Numbers received exceeds the expected sequence (e.g., more parts submitted than numbered in the sequence), it will be flagged as an error.
  • Duplicate Split Numbers Received in the Submission If any Split Numbers are duplicated within the submission, it will be identified as a duplicate and result in an error, as each Split Number must be unique within the transaction. Note: The Split Number is a required element when large payloads are sent in multiple splits within the same transaction. If there are multiple payloads, a Split Number must be provided, and the Parent Unique ID must also be present to ensure proper identification and sequencing of the split submissions.
  • Length Requirements The Split Number must have a minimum length of 3 characters and a maximum length of 5 characters.
  • Numeric with Dash The Split Number must be numeric and include a dash between the numbers.
  • Format Requirements The Split Number must follow the format: number-dash-number. For example: 1-1, 12-34, etc.
  • Maximum Split Submissions A maximum of 99 split submissions is allowed, meaning the highest acceptable Split Number is 99-99.
    		•  O
    13 Class Code category CodableConcept The name displayed to communicate the meaning of the classCode will have a single value for each classCode value, ensuring clear and consistent communication of its meaning to a human user. Valid Class Code Invalid or Missing Class Code Class code string must be present The Class Code must always be "1" for all the Content Type Codes/Line of Business IDs R
    14 Format code content.format Coding esMD FHIR supports the following types of clinical documents:
  • Unstructured clinical notes and scanned documents (HITSP C62).
  • Structured clinical summaries (HITSP C32). HITSP C32 provides detailed guidance for exchanging clinical summaries between different healthcare systems. The C32 specification defines the format for the Continuity of Care Document (CCD), which is used to share structured clinical data in a standardized way. esMD supports structured clinical summaries in Clinical XML format. If a clinical summary contains unstructured information, the embedded format must still be PDF, XML, or JSON. In this case, the appropriate format code should be applied based on the document's content and encoding.
    		• Valid Format Code Invalid or Missing Format Code Format code string must be present The esMD system has customized and created the following format codes are supported: PDF Document: Format Code: urn:ihe:iti:xds-sd:pdf:2008 Text Document: Format Code: urn:ihe:iti:xds:2017:mimeTypeSufficient R
    15 Health Care Facilitytype code context.facilityType CodableConcept The facility type code represents the type of organizational or provider setting in which the claim or clinical encounter occurred, or where the documented act took place. HL7 Facility Types: Instead of listing individual HL7 codes, the entire HL7 v3 RoleCode system () is referenced. This allows the ValueSet to include all HL7-defined facility types, such as hospitals, ambulatory care centers, skilled nursing facilities, and more. Valid Health Care Facility Type Code Invalid or Missing String or Empty HealthcareFacilityType code The esMD system has created custom Facility Types: hih: Health Information Handler hcp: Health Care Provider cms-rc: CMS Review Contractor These codes are defined in a custom code system, available at: . R
    16 Confidentiality Code securityLabel CodableConcept The confidentiality code specifies the level of confidentiality for each attached clinical document, indicating the sensitivity and access restrictions associated with the document. Valid Confidentiality Code Invalid or Missing code Empty Confidentiality Code string For the esMD, the value is always ‘V’: V- very restricted R
    17 Response Type Category Esmd-Ext-ResponseTypeCategory The Response Type Category identifies the different types of responses from Handlers (HIHs) or Providers. These responses have pre-determined values, which are decided by the Review Contractors (RCs), in addition to the Content Type Code (CTC). The Response Type Category element is optional and if submitted the system will do the length check only and ensures it does not exceed more than the defined length. Length 0-100 characters and no format check. O
    18 MIME type content.attachment.contentType code A MIME type (or media type) is a method of identifying file formats and content transmitted over the internet. MIME types allow browsers to recognize the file type of a file sent via HTTP by the web server. This enables the browser to select an appropriate method for displaying the content. Common MIME types include, for example: text/html for HTML files image/jpeg for JPEG image files Mime Type must be present. Invalid MIME type format Invalid length and format The MIME type must have a length between 1 and 64 characters. The format for Mime type must be "application/pdf" for PDF documents. Note: MIME type values are case-sensitive, so it must be entered exactly as "application/pdf". R
    19 Hash content.attachment.hash base64Binary A hash key is a value generated from a string of text in a way that is nearly impossible to turn back into the original text. In the context of your statement: The hash key of the XDR payload (C62 document attachment) is generated using the SHA-1 hash algorithm. This hash key is a unique identifier for the content, ensuring that any changes to the document will result in a different hash value, allowing for integrity verification of the document. The system will check the Hash element string is present, if submitted the system will do the length check only and ensures it does not exceed more than the defined length. The Length must be 1 to 256 characters only and no format check any characters are allowed. R
    20 Creation Time date Type is instant The creation date and time stamp is an element that represents the date and time when the Health Information Handler (HIH) created the document that is being processed by esMD. Creation Timestamp is required, and the system will ensure the following: Timestamp is present. Valid format as per FHIR standards (e.g., YYYY-MM-DDThh:mm:ss+zz:zz). Missing timestamp will trigger an error.
  • Timestamp Format Validation: The timestamp is validated to ensure it follows the correct format: YYYY-MM-DDThh:mm:ss+zz:zz Where: YYYY = Year MM = Month DD = Day hh = Hour mm = Minute ss = Second +zz:zz = Timezone offset
    		• R
    21 Language Code content.attachment.language The language code specifies the human language used for the character data in the document.
  • Valid Language Code
  • Invalid or Missing Language Code
    		•  The language code must always be "en-us". The length of the language code must be between 1 and 16 characters. R
    22 Document ID Id A Document ID is a unique identifier that must match between the ID inside the bundle metadata and the document ID assigned to the attached payload.
  • Missing Document ID
  • Invalid Document ID
  • Document ID in the metadata does not match with the document in the attached document
  • Payload successfully decoded for Document
    		•  The length must be between 1 and 256 characters. R

    Section 3: esMD Functional Specifications Submission Set and Metadata Attributes

    This section outlines the Functional Specifications Submission Set and Metadata Attributes for the following Lines of Business (LOBs) within the esMD system:

    1. Advance Determination of Medicare Coverage (ADMC) Submissions (CTC 10) The ADMC submissions (CTC 10) are used by healthcare providers to request an advance determination from Medicare on whether a service or item is covered before it is provided. This submission set allows the provider to submit necessary documentation to receive a preemptive coverage decision. The metadata attributes ensure accurate processing and tracking of these requests within the esMD system.

    2. Prior Authorization/Pre-Certification Requests (PA/PCR) Submissions (CTC 8.1, 8.3,8.4, 8.5 and 8.6) PA/PCR submissions, which include specific programs such as Ambulance, HHPCR (Home Health Prior Authorization Requests), DMEPOS (Durable Medical Equipment, Prosthetics, Orthotics, and Supplies), HOPD (Hospital Outpatient Department), and IRF (Inpatient Rehabilitation Facility), are used to submit documentation for prior authorization or pre-certification of services and procedures before they are performed.

      • This series of submissions ensures that the requested services are authorized by Medicare prior to their provision. Each program type includes its own metadata requirements that are essential for the proper handling, processing, and approval of services. The metadata attributes associated with these submissions support various stages of the authorization process, including:
        • Initial submission of service requests,
        • Follow-up documentation to clarify details or respond to inquiries,
        • Tracking and processing of the approval or denial decision.

    Table 3: Advance Determination of Medicare Coverage (ADMC) and Prior Authorization/Pre-Certification (PA/PCR) Submissions Mapping

    ID XDR METADATA ELEMENT FHIR ELEMENT/EXTENSION ELEMENT DESCRIPTION VALIDATION RULE LENGTH & FORMAT REQUIRED/OPTIONAL
    1 Unique ID Esmd-Ext-UniqueId A globally unique identifier is assigned by the Health Information Handler (HIH) to each document within the Submission Set. This Unique ID is included in the response sent back to the HIH, ensuring consistent tracking and identification of each document throughout the submission process.
  • Invalid Length and Format of Unique ID
  • A Unique ID that exceeds 64 characters in length is considered invalid. The Unique ID should comply with the defined length constraints.
  • Duplicate Unique ID
    • Each Unique ID must be unique within the system to maintain data integrity.
  • Length must be between 1 and 64 Characters
  • Format Must Be Alphanumeric
  • Can contain Dashes and Underscores
    		•  R
    2 Parent Unique ID Esmd-Ext-ParentUniqueId The Parent UniqueId is utilized by the esMD System to group multiple submission files into a single transaction when a Health Information Handler (HIH) needs to divide a large payload into multiple submissions. This Parent UniqueId serves as the unique identifier for the initial transaction, and it is included in all subsequent transactions related to the split payload. By using the Parent UniqueId, Review Contractors can efficiently combine and review all submissions associated with a single payload. This ensures a smooth processing experience while maintaining the integrity of the clinical documentation.
  • Parent Unique ID must be present if a split payload is sent.
  • Missing Parent Unique ID
    • If a Split Number is present for multiple submissions, a Parent Unique ID must be provided. The absence of the Parent Unique ID in this scenario will be flagged as an error, as it is necessary to associate all split submissions with the initial transaction.
  • Length must be between 1 and 64 Characters
  • Format Must Be Alphanumeric
  • Can contain Dashes and Underscores and no other special characters are allowed.
    		•  R
    3 HIH OID Esmd-Ext-SenderOid Coding A Globally Unique Identifier (GUID), in OID (Object Identifier) format, is used to uniquely identify the Health Information Handler (HIH). This identifier ensures that the HIH can be distinctly recognized across systems, providing a consistent and reliable reference within the health information management process.
  • Invalid HIH OID
  • Missing HIH OID
  • Valid format check of HIH OID and CTC
  • Invalid combination of HIH OID and Content Type Code
    		•
  • Length must be between 1 to 64 Characters
  • Format must be as stated: "urn:oid:1.3.6.1.4.1.101420.6.1"
    		•  R
    4 RC OID Esmd-Ext-IntendedRecipient Coding The Intended Recipient refers to the organization (RC) that will receive the message from the sender (HIH) containing the esMD Claim supporting documents. This Intended Recipient will be uniquely identified using an OID (Object Identifier) issued by HL7.
  • Invalid RC OID
  • Missing RC OID
  • Valid format check of RC OID and CTC.
    • 24 Invalid combination of RC OID and Content Type Code
  • Length must be between 1 to 64 Characters
  • Format must be as stated: "urn:oid:1.3.6.1.4.1.101420.6.1"
    		•  R
    5 Content Type Code/Line Of Business Id Esmd-Ext-LinesOfBusinessId The Content Type Code identifies the specific line of business for which the provider or Health Information Handler (HIH) is submitting the request.
  • Content Type Code or Line of Business ID must be part of esMD and in active status
  • Invalid Content Type Code
  • Content Type Code Missing
    		•
  • Length 1 -16
  • Format must be numeric with period Ex: "1 or 1.1or 11"
    		•  R
    6 NPI Esmd-Ext-NPI Represents the provider's NPI or institution's NPI that authored the individual document included in the Submission Set. Invalid NPI Missing NPI Missing String
  • Length must be 10 numeric.
  • Format or Example: 1234567890
    		•  R
    8 Comments - Notes Comments associated with the Submission Set are provided as free-form text. The Health Information Handler (HIH) or Provider may include additional details or clarifications when submitting the documentation, if necessary. No check any value sent in the string will be taken and processed. The max character limit is 256 in length. Length 0-256 characters O
    9 Submission Time FHIR Date Format The Submission Time refers to the specific point in time when the Bundle Submission Set was created by the Health Information Handler (HIH). Timestamp is required, and the system will ensure the following:
  • Timestamp is present.
  • Valid format as per FHIR standards (e.g., YYYY-MM-DDThh:mm:ss+zz:zz).
  • Missing timestamp will trigger an error.
    		•
  • Timestamp Format Validation: The timestamp is validated to ensure it follows the correct format: YYYY-MM-DDThh:mm:ss+zz:zz Where: YYYY = Year MM = Month DD = Day hh = Hour mm = Minute ss = Second +zz:zz = Timezone offset
    		• R
    10 Split Number Esmd-Ext-SplitNumber The Split Number is used by the esMD system when a Health Information Handler (HIH) submits a large payload that needs to be divided into smaller parts for efficient submission and delivery. It uniquely identifies the sequence of each part in a series of split submissions. This ensures that all parts of the submission can be correctly combined and reviewed as a complete set by the receiving Review Contractor (RC). The Split Number helps maintain the order and integrity of the submission, streamlining the processing of large payloads across multiple transactions.
  • Invalid Split Number Format and Length
    • If the Split Number does not adhere to the required format or exceeds the allowed length, it will be flagged as invalid.
  • Missing Split Number Sequence
    • If a Split Number sequence is missing (i.e., if a part of the submission does not have a properly assigned sequence number), it will be considered an error and will prevent proper processing.
  • More Split Numbers Received Than Numbered
    • If the number of Split Numbers received exceeds the expected sequence (e.g., more parts submitted than numbered in the sequence), it will be flagged as an error.
  • Duplicate Split Numbers Received in the Submission
    • If any Split Numbers are duplicated within the submission, it will be identified as a duplicate and result in an error, as each Split Number must be unique within the transaction. Note: The Split Number is a required element when large payloads are sent in multiple splits within the same transaction. If there are multiple payloads, a Split Number must be provided, and the Parent Unique ID must also be present to ensure proper identification and sequencing of the split submissions.
  • Length Requirements
    • The Split Number must have a minimum length of 3 characters and a maximum length of 5 characters.
  • Numeric with Dash
    • The Split Number must be numeric and include a dash between the numbers.
  • Format Requirements
    • The Split Number must follow the format: number-dash-number. For example: 1-1, 12-34, etc.
  • Maximum Split Submissions
    • A maximum of 99 split submissions is allowed, meaning the highest acceptable Split Number is 99-99.     		O
    12 Attachment Control Number (ACN) Esmd-Ext-AttachmentControlNumber The identification number provided by the requester in element PWK06 is used when the requester has additional documentation associated with the health services review that applies to the service requested. This number helps to link the X12N 278 5010 request with the supporting documentation received in the XDR format. This identification number ensures that the documentation is properly associated with the corresponding service request, facilitating accurate tracking, processing, and review of the additional information provided. It plays a critical role in ensuring the seamless integration of the health service request and its supporting documentation in the electronic submission process. The system will perform a format check to ensure that the Attachment Control Number meets the following criteria if provided by HIH: It has the correct length. It contains only alphanumeric characters. It does not exceed the specified size if submitted. The length must be 1 to 40 characters long. It can only contain alphanumeric characters (letters and numbers), with no special characters allowed. The value cannot contain spaces or be made up entirely of spaces. O
    13 Class Code category CodableConcept The name displayed to communicate the meaning of the classCode will have a single value for each classCode value, ensuring clear and consistent communication of its meaning to a human user. Valid Class Code Invalid or Missing Class Code Class code string must be present The Class Code must always be "1" for all the Content Type Codes/Line of Business IDs R
    14 Format code content.format Coding esMD FHIR supports the following types of clinical documents:
  • Unstructured clinical notes and scanned documents (HITSP C62).
  • Structured clinical summaries (HITSP C32).
    • HITSP C32 provides detailed guidance for exchanging clinical summaries between different healthcare systems. The C32 specification defines the format for the Continuity of Care Document (CCD), which is used to share structured clinical data in a standardized way. esMD supports structured clinical summaries in Clinical XML format. If a clinical summary contains unstructured information, the embedded format must still be PDF, XML, or JSON. In this case, the appropriate format code should be applied based on the document's content and encoding.     		Valid Format Code Invalid or Missing Format Code Format code string must be present The esMD system has customized and created the following format codes are supported: PDF Document: Format Code: urn:ihe:iti:xds-sd:pdf:2008 Text Document: Format Code: urn:ihe:iti:xds:2017:mimeTypeSufficient R
    15 Healthcare Facility type code context.facilityType CodableConcept The facility type code represents the type of organizational or provider setting in which the claim or clinical encounter occurred, or where the documented act took place. HL7 Facility Types: Instead of listing individual HL7 codes, the entire HL7 v3 RoleCode system () is referenced. This allows the ValueSet to include all HL7-defined facility types, such as hospitals, ambulatory care centers, skilled nursing facilities, and more. Valid Health Care Facility Type Code Invalid or Missing String or Empty HealthcareFacilityType code The esMD system has created custom Facility Types: hih: Health Information Handler hcp: Health Care Provider cms-rc: CMS Review Contractor These codes are defined in a custom code system, available at: . R
    16 Confidentiality Code securityLabel CodableConcept The confidentiality code specifies the level of confidentiality for each attached clinical document, indicating the sensitivity and access restrictions associated with the document. Valid Confidentiality Code Invalid or Missing code Empty Confidentiality Code string For the esMD, the value is always ‘V’: V- very restricted R
    17 Response Type Category Esmd-Ext-ResponseTypeCategory The Response Type Category identifies the different types of responses from Handlers (HIHs) or Providers. These responses have pre-determined values, which are decided by the Review Contractors (RCs), in addition to the Content Type Code (CTC). The Response Type Category element is optional and if submitted the system will do the length check only and ensures it does not exceed more than the defined length. Length 0-100 characters and no format check. O
    18 MIME type content.attachment.contentType code A MIME type (or media type) is a method of identifying file formats and content transmitted over the internet. MIME types allow browsers to recognize the file type of a file sent via HTTP by the web server. This enables the browser to select an appropriate method for displaying the content. Common MIME types include, for example: text/html for HTML files image/jpeg for JPEG image files Mime Type must be present. Invalid MIME type format Invalid length and format The MIME type must have a length between 1 and 64 characters. The format for Mime type must be "application/pdf" for PDF documents. Note: MIME type values are case-sensitive, so it must be entered exactly as "application/pdf". R
    19 Hash content.attachment.hash base64Binary A hash key is a value generated from a string of text in a way that is nearly impossible to turn back into the original text. In the context of your statement: The hash key of the XDR payload (C62 document attachment) is generated using the SHA-1 hash algorithm. This hash key is a unique identifier for the content, ensuring that any changes to the document will result in a different hash value, allowing for integrity verification of the document. The system will check the Hash element string is present, if submitted the system will do the length check only and ensures it does not exceed more than the defined length. The Length must be 1 to 256 characters only and no format check any characters are allowed. R
    20 Creation Time date Type is instant The creation date and time stamp is an element that represents the date and time when the Health Information Handler (HIH) created the document that is being processed by esMD. Creation Timestamp is required, and the system will ensure the following: Timestamp is present. Valid format as per FHIR standards (e.g., YYYY-MM-DDThh:mm:ss+zz:zz). Missing timestamp will trigger an error.
  • Timestamp Format Validation: The timestamp is validated to ensure it follows the correct format: YYYY-MM-DDThh:mm:ss+zz:zz Where: YYYY = Year MM = Month DD = Day hh = Hour mm = Minute ss = Second +zz:zz = Timezone offset
    		• R
    21 Language Code content.attachment.language The language code specifies the human language used for the character data in the document.
  • Valid Language Code
  • Invalid or Missing Language Code
    		•  The language code must always be "en-us". The length of the language code must be between 1 and 16 characters. R
    22 Document ID Id A Document ID is a unique identifier that must match between the ID inside the bundle metadata and the document ID assigned to the attached payload.
  • Missing Document ID
  • Invalid Document ID
  • Document ID in the metadata does not match with the document in the attached document
  • Payload successfully decoded for Document
    		•  The length must be between 1 and 256 characters. R

    Section 4: esMD Functional Specifications Submission Set and Metadata Attributes for ADR PERM

    The ADR PERM (Additional Documentation Request - Permanent Program) is a program that facilitates the permanent handling of Additional Documentation Requests (ADRs) under the Medicare system. This program allows Medicare Administrative Contractors (MACs) to request additional documentation from healthcare providers to support a claim or service under review.

    The ADR PERM program is designed to streamline the submission process for providers by ensuring that all requested documentation is submitted electronically through systems like esMD (electronic Submission of Medical Documentation). The system will facilitate ongoing management of ADRs, providing permanent metadata attributes that allow the following:

    • Efficient tracking of documentation submissions
    • Timely processing of requested claims
    • Support for the review and audit process for ongoing or repetitive ADR requests

    The ADR PERM program helps ensure that all documentation is associated with the correct claims and services, improving the efficiency and compliance of the ADR process.

    Table 4: ADR Perm

    ID XDR METADATA ELEMENT FHIR ELEMENT/EXTENSION ELEMENT DESCRIPTION VALIDATION RULE LENGTH & FORMAT REQUIRED/OPTIONAL
    1 Unique ID Esmd-Ext-UniqueId A globally unique identifier is assigned by the Health Information Handler (HIH) to each document within the Submission Set. This Unique ID is included in the response sent back to the HIH, ensuring consistent tracking and identification of each document throughout the submission process.
  • Invalid Length and Format of Unique ID
  • A Unique ID that exceeds 64 characters in length is considered invalid. The Unique ID should comply with the defined length constraints.
  • Duplicate Unique ID Each Unique ID must be unique within the system to maintain data integrity.
    		•
  • Length must be between 1 and 64 Characters
  • Format Must Be Alphanumeric
  • Can contain Dashes and Underscores
    		•  R
    2 Parent Unique ID Esmd-Ext-ParentUniqueId The Parent UniqueId is utilized by the esMD System to group multiple submission files into a single transaction when a Health Information Handler (HIH) needs to divide a large payload into multiple submissions. This Parent UniqueId serves as the unique identifier for the initial transaction, and it is included in all subsequent transactions related to the split payload. By using the Parent UniqueId, Review Contractors can efficiently combine and review all submissions associated with a single payload. This ensures a smooth processing experience while maintaining the integrity of the clinical documentation.
  • Parent Unique ID must be present if a split payload is sent.
  • Missing Parent Unique ID If a Split Number is present for multiple submissions, a Parent Unique ID must be provided. The absence of the Parent Unique ID in this scenario will be flagged as an error, as it is necessary to associate all split submissions with the initial transaction.
  • Length must be between 1 and 64 Characters
  • Format Must Be Alphanumeric
  • Can contain Dashes and Underscores and no other special characters are allowed.
    		•  R
    3 HIH OID Esmd-Ext-SenderOid Coding A Globally Unique Identifier (GUID), in OID (Object Identifier) format, is used to uniquely identify the Health Information Handler (HIH). This identifier ensures that the HIH can be distinctly recognized across systems, providing a consistent and reliable reference within the health information management process.
  • Invalid HIH OID
  • Missing HIH OID
  • Valid format check of HIH OID and CTC
  • Invalid combination of HIH OID and Content Type Code
    		•
  • Length must be between 1 to 64 Characters
  • Format must be as stated: "urn:oid:1.3.6.1.4.1.101420.6.1"
    		•  R
    4 RC OID Esmd-Ext-IntendedRecipient Coding The Intended Recipient refers to the organization (RC) that will receive the message from the sender (HIH) containing the esMD Claim supporting documents. This Intended Recipient will be uniquely identified using an OID (Object Identifier) issued by HL7.
  • Invalid RC OID
  • Missing RC OID
  • Valid format check of RC OID and CTC. 24 Invalid combination of RC OID and Content Type Code
    		•
  • Length must be between 1 to 64 Characters
  • Format must be as stated: "urn:oid:1.3.6.1.4.1.101420.6.1"
    		•  R
    5 Content Type Code/Line Of Business Id Esmd-Ext-LinesOfBusinessId The Content Type Code identifies the specific line of business for which the provider or Health Information Handler (HIH) is submitting the request.
  • Content Type Code or Line of Business ID must be part of esMD and in active status
  • Invalid Content Type Code
  • Content Type Code Missing
    		•
  • Length 1 -16
  • Format must be numeric with period Ex: "1 or 1.1or 11"
    		•  R
    6 NPI Esmd-Ext-NPI Represents the provider's NPI or institution's NPI that authored the individual document included in the Submission Set. Invalid NPI Missing NPI Missing String
  • Length must be 10 numeric.
  • Format or Example: 1234567890
    		•  R
    8 Case ID Esmd-Ext-CaseId The Case Identifier is generated by the Review Contractor (RC) to open a claim-specific case. The Case ID can be submitted in either Standard or Composite Format, depending on the requirements of the Line of Business (LOB). The Case ID is required element for ADR Perm and the system will ensure it is of the right length and format. Checks the Case ID is present. Valid Format check Invalid Length and Format triggers an error
  • The Case ID must be exactly 11 characters long.
  • It must be alphanumeric only (letters and numbers), with no special characters allowed.
    		•  O
    9 Comments - Notes NA Comments associated with the Submission Set are provided as free-form text. The Health Information Handler (HIH) or Provider may include additional details or clarifications when submitting the documentation, if necessary. No check any value sent in the string will be taken and processed. The max character limit is 256 in length. Length 0-256 characters O
    10 Submission Time FHIR Date Format The Submission Time refers to the specific point in time when the Bundle Submission Set was created by the Health Information Handler (HIH). Timestamp is required, and the system will ensure the following: Timestamp is present. Valid format as per FHIR standards (e.g., YYYY-MM-DDThh:mm:ss+zz:zz). Missing timestamp will trigger an error.
  • Timestamp Format Validation: The timestamp is validated to ensure it follows the correct format: YYYY-MM-DDThh:mm:ss+zz:zz Where: YYYY = Year MM = Month DD = Day hh = Hour mm = Minute ss = Second +zz:zz = Timezone offset
    		• R
    11 Split Number Esmd-Ext-SplitNumber The Split Number is used by the esMD system when a Health Information Handler (HIH) submits a large payload that needs to be divided into smaller parts for efficient submission and delivery. It uniquely identifies the sequence of each part in a series of split submissions. This ensures that all parts of the submission can be correctly combined and reviewed as a complete set by the receiving Review Contractor (RC). The Split Number helps maintain the order and integrity of the submission, streamlining the processing of large payloads across multiple transactions.
  • Invalid Split Number Format and Length If the Split Number does not adhere to the required format or exceeds the allowed length, it will be flagged as invalid.
  • Missing Split Number Sequence If a Split Number sequence is missing (i.e., if a part of the submission does not have a properly assigned sequence number), it will be considered an error and will prevent proper processing.
  • More Split Numbers Received Than Numbered If the number of Split Numbers received exceeds the expected sequence (e.g., more parts submitted than numbered in the sequence), it will be flagged as an error.
  • Duplicate Split Numbers Received in the Submission If any Split Numbers are duplicated within the submission, it will be identified as a duplicate and result in an error, as each Split Number must be unique within the transaction. Note: The Split Number is a required element when large payloads are sent in multiple splits within the same transaction. If there are multiple payloads, a Split Number must be provided, and the Parent Unique ID must also be present to ensure proper identification and sequencing of the split submissions.
  • Length Requirements The Split Number must have a minimum length of 3 characters and a maximum length of 5 characters.
  • Numeric with Dash The Split Number must be numeric and include a dash between the numbers.
  • Format Requirements The Split Number must follow the format: number-dash-number. For example: 1-1, 12-34, etc.
  • Maximum Split Submissions A maximum of 99 split submissions is allowed, meaning the highest acceptable Split Number is 99-99.
    		•  O
    13 Class Code category CodableConcept The name displayed to communicate the meaning of the classCode will have a single value for each classCode value, ensuring clear and consistent communication of its meaning to a human user. Valid Class Code Invalid or Missing Class Code Class code string must be present The Class Code must always be "1" for all the Content Type Codes/Line of Business IDs R
    14 Format code content.format Coding esMD FHIR supports the following types of clinical documents:
  • Unstructured clinical notes and scanned documents (HITSP C62).
  • Structured clinical summaries (HITSP C32). HITSP C32 provides detailed guidance for exchanging clinical summaries between different healthcare systems. The C32 specification defines the format for the Continuity of Care Document (CCD), which is used to share structured clinical data in a standardized way. esMD supports structured clinical summaries in Clinical XML format. If a clinical summary contains unstructured information, the embedded format must still be PDF, XML, or JSON. In this case, the appropriate format code should be applied based on the document's content and encoding.
    		• Valid Format Code Invalid or Missing Format Code Format code string must be present The esMD system has customized and created the following format codes are supported: PDF Document: Format Code: urn:ihe:iti:xds-sd:pdf:2008 Text Document: Format Code: urn:ihe:iti:xds:2017:mimeTypeSufficient R
    15 Health Care Facilitytype code context.facilityType CodableConcept The facility type code represents the type of organizational or provider setting in which the claim or clinical encounter occurred, or where the documented act took place. HL7 Facility Types: Instead of listing individual HL7 codes, the entire HL7 v3 RoleCode system () is referenced. This allows the ValueSet to include all HL7-defined facility types, such as hospitals, ambulatory care centers, skilled nursing facilities, and more. Valid Health Care Facility Type Code Invalid or Missing String or Empty HealthcareFacilityType code The esMD system has created custom Facility Types: hih: Health Information Handler hcp: Health Care Provider cms-rc: CMS Review Contractor These codes are defined in a custom code system, available at: . R
    16 Confidentiality Code securityLabel CodableConcept The confidentiality code specifies the level of confidentiality for each attached clinical document, indicating the sensitivity and access restrictions associated with the document. Valid Confidentiality Code Invalid or Missing code Empty Confidentiality Code string For the esMD, the value is always ‘V’: V- very restricted R
    17 Response Type Category Esmd-Ext-ResponseTypeCategory The Response Type Category identifies the different types of responses from Handlers (HIHs) or Providers. These responses have pre-determined values, which are decided by the Review Contractors (RCs), in addition to the Content Type Code (CTC). The Response Type Category element is optional and if submitted the system will do the length check only and ensures it does not exceed more than the defined length. Length 0-100 characters and no format check. O
    18 MIME type content.attachment.contentType code A MIME type (or media type) is a method of identifying file formats and content transmitted over the internet. MIME types allow browsers to recognize the file type of a file sent via HTTP by the web server. This enables the browser to select an appropriate method for displaying the content. Common MIME types include, for example: text/html for HTML files image/jpeg for JPEG image files Mime Type must be present. Invalid MIME type format Invalid length and format The MIME type must have a length between 1 and 64 characters. The format for Mime type must be "application/pdf" for PDF documents. Note: MIME type values are case-sensitive, so it must be entered exactly as "application/pdf". R
    19 Hash content.attachment.hash base64Binary A hash key is a value generated from a string of text in a way that is nearly impossible to turn back into the original text. In the context of your statement: The hash key of the XDR payload (C62 document attachment) is generated using the SHA-1 hash algorithm. This hash key is a unique identifier for the content, ensuring that any changes to the document will result in a different hash value, allowing for integrity verification of the document. The system will check the Hash element string is present, if submitted the system will do the length check only and ensures it does not exceed more than the defined length. The Length must be 1 to 256 characters only and no format check any characters are allowed. R
    20 Creation Time date Type is instant The creation date and time stamp is an element that represents the date and time when the Health Information Handler (HIH) created the document that is being processed by esMD. Creation Timestamp is required, and the system will ensure the following: Timestamp is present. Valid format as per FHIR standards (e.g., YYYY-MM-DDThh:mm:ss+zz:zz). Missing timestamp will trigger an error.
  • Timestamp Format Validation: The timestamp is validated to ensure it follows the correct format: YYYY-MM-DDThh:mm:ss+zz:zz Where: YYYY = Year MM = Month DD = Day hh = Hour mm = Minute ss = Second +zz:zz = Timezone offset
    		• R
    21 Language Code content.attachment.language The language code specifies the human language used for the character data in the document.
  • Valid Language Code
  • Invalid or Missing Language Code
    		•  The language code must always be "en-us". The length of the language code must be between 1 and 16 characters. R
    22 Document ID Id A Document ID is a unique identifier that must match between the ID inside the bundle metadata and the document ID assigned to the attached payload.
  • Missing Document ID
  • Invalid Document ID
  • Document ID in the metadata does not match with the document in the attached document
  • Payload successfully decoded for Document
    		•  The length must be between 1 and 256 characters. R