+}
diff --git a/src/components/alternative-test-methods/tempFileForStructure-deleteWhenFilesAdded b/src/components/alternative-test-methods/tempFileForStructure-deleteWhenFilesAdded
new file mode 100644
index 00000000..e69de29b
diff --git a/src/components/archived/ArchiveCard.tsx b/src/components/archived/ArchiveCard.tsx
new file mode 100644
index 00000000..6d09b137
--- /dev/null
+++ b/src/components/archived/ArchiveCard.tsx
@@ -0,0 +1,38 @@
+import * as React from 'react'
+import Card from '@mui/material/Card'
+import CardContent from '@mui/material/CardContent'
+import Typography from '@mui/material/Typography'
+import { Button, CardActions } from '@mui/material'
+import ArrowForwardIcon from '@mui/icons-material/ArrowForward'
+
+export interface CriteriaCardProps {
+ cardHeader: string
+ description: string
+}
+const ArchiveCard = ({ cardHeader, description }: CriteriaCardProps) => {
+ return (
+
+
+
+ {cardHeader}
+
+
+ {description}
+
+
+
+ }>
+ Go
+
+
+
+ )
+}
+
+export default ArchiveCard
diff --git a/src/components/archived/ArchiveFilter.tsx b/src/components/archived/ArchiveFilter.tsx
new file mode 100644
index 00000000..50021884
--- /dev/null
+++ b/src/components/archived/ArchiveFilter.tsx
@@ -0,0 +1,25 @@
+import React from 'react'
+import Button from '@mui/material/Button'
+const ArchiveFilter = () => {
+ return (
+
+ )
+}
+
+export default ArchiveFilter
diff --git a/src/components/archived/ArchiveHome.tsx b/src/components/archived/ArchiveHome.tsx
new file mode 100644
index 00000000..941e38b8
--- /dev/null
+++ b/src/components/archived/ArchiveHome.tsx
@@ -0,0 +1,105 @@
+// MUI Imports
+import BannerBox from '../shared/BannerBox'
+import { Box, Link, Container } from '@mui/material'
+// Global Imports
+import React from 'react'
+// Styles
+import palette from '@/styles/palette'
+import ArchiveCard from './ArchiveCard'
+import ArchiveFilter from './ArchiveFilter'
+import SubMenu, { menuProps } from '@/components/shared/SubMenu'
+// Images
+
+const ArchiveHome = () => {
+ const menuItems: menuProps[] = [
+ { heading: 'All', href: '' },
+ { heading: 'C-CDA', href: '' },
+ { heading: 'Direct', href: '' },
+ { heading: 'Edge', href: '' },
+ { heading: 'XDM', href: '' },
+ { heading: 'Other', href: '' },
+ { heading: 'Contact Us', href: '' },
+ ]
+
+ return (
+
+ {/* Global Header */}
+
+ Archived
+
+ }
+ heading={'Archived tools, files and other additional content'}
+ description={
+ <>
+ Unearth a treasure trove of archived resources including tools files and more! Please be aware that these
+ materials are no longer actively maintained. Despite this, they offer valuable insights and historical
+ context. Dive into our curated collection to explore and discover valuable resources for your projects and
+ endeavors!
+
+ }
+ />
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default ArchiveHome
diff --git a/src/components/archived/CardList.js b/src/components/archived/CardList.js
new file mode 100644
index 00000000..75aaf995
--- /dev/null
+++ b/src/components/archived/CardList.js
@@ -0,0 +1,14 @@
+import React from 'react'
+import { Card } from '@mui/material'
+
+const CardList = ({ cards }) => {
+ return (
+
+ {cards.map((card, index) => (
+
+ ))}
+
+ )
+}
+
+export default CardList
diff --git a/src/components/archived/SubMenuButton.tsx b/src/components/archived/SubMenuButton.tsx
new file mode 100644
index 00000000..0576866f
--- /dev/null
+++ b/src/components/archived/SubMenuButton.tsx
@@ -0,0 +1,24 @@
+import React from 'react'
+import { Button } from '@mui/material'
+
+export interface SubMenuProps {
+ heading: string
+}
+
+const SubMenuButton = ({ heading }: SubMenuProps) => {
+ return (
+
+ )
+}
+
+export default SubMenuButton
diff --git a/src/components/c-cda/CCDAHome.tsx b/src/components/c-cda/CCDAHome.tsx
new file mode 100644
index 00000000..c28e6876
--- /dev/null
+++ b/src/components/c-cda/CCDAHome.tsx
@@ -0,0 +1,144 @@
+import { Box, Container, Divider } from '@mui/material'
+import Link from 'next/link'
+import BannerBox from '@shared/BannerBox'
+import styles from '@shared/styles.module.css'
+import CardWithImage from '@shared/CardWithImage'
+import uscdiv3 from '@public/c-cda/uscdi-v3.svg'
+import uscdiv1 from '@public/c-cda/uscdi-v1.svg'
+import scorecard from '@public/c-cda/scorecard.svg'
+import oneclick from '@public/c-cda/oneclick.svg'
+import placeholder from '@public/c-cda/placeholder.svg'
+import SectionHeader from '../shared/SectionHeader'
+
+const CCDAHome = () => {
+ const maxWidth = 550
+ const certCardMaxWidth = 350
+ const flexibleBox = { display: 'flex', gap: 4, flexDirection: 'row', width: '100%', justifyContent: 'space-between' }
+ return (
+ <>
+ {/* Global Header */}
+
+ C-CDA
+
+ }
+ heading={'Consolidated Clinical Document Architecture (C-CDA) Testing & More'}
+ description={
+ <>
+ Consolidated Clinical Document Architecture (C-CDA) is a standardized framework used in healthcare to
+ structure and share various clinical documents electronically. It improves patient care coordination by
+ ensuring consistent and accurate exchange of information between different healthcare systems and providers.
+ By using C-CDA validators, healthcare organizations, EHR vendors, and other stakeholders can identify and
+ rectify issues in C-CDA documents before sharing them with other systems, promoting data accuracy,
+ interoperability, and overall patient safety.
+
+ }
+ />
+ {/* Main Content */}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default CCDAHome
diff --git a/src/components/c-cda/validation/ResultsStatusCard.tsx b/src/components/c-cda/validation/ResultsStatusCard.tsx
new file mode 100644
index 00000000..13d4a07c
--- /dev/null
+++ b/src/components/c-cda/validation/ResultsStatusCard.tsx
@@ -0,0 +1,63 @@
+import React from 'react'
+import { Card, Typography, Box } from '@mui/material'
+
+type CardType = 'error' | 'warning' | 'info'
+
+interface ResultsStatusCardProps {
+ type: CardType
+ count: number
+ messages: string[]
+}
+
+const ResultsStatusCard: React.FC = ({ type, count, messages }) => {
+ const colorMap = {
+ error: '#FF5252',
+ warning: '#83380E',
+ info: '#122953',
+ }
+
+ return (
+
+
+
+
+
+ {`${count} ${type.charAt(0).toUpperCase() + type.slice(1)}`}
+
+ {messages.map((message, index) => (
+
+ {message}
+
+ ))}
+
+
+ )
+}
+
+export default ResultsStatusCard
diff --git a/src/components/c-cda/validation/ValidationResultsSummary.tsx b/src/components/c-cda/validation/ValidationResultsSummary.tsx
new file mode 100644
index 00000000..375b821d
--- /dev/null
+++ b/src/components/c-cda/validation/ValidationResultsSummary.tsx
@@ -0,0 +1,55 @@
+import React from 'react'
+import { Typography, Box } from '@mui/material'
+import ResultsStatusCard from './ResultsStatusCard'
+import ValidationStatusIndicator from './ValidationStatusIndicator'
+
+export default function ValidatorResultsSummary() {
+ const errors = ['1 Error in C-CDA MDHT Conformance']
+ const warnings = ['1 Warning']
+ const infos = ['1 Info', '1 Info', '1 Info']
+ return (
+
+
+ Summary
+
+
+ Thank you for using our CCDA (Consolidated Clinical Document Architecture) Validator. We have processed your
+ CCDA file and here is a summary of the validation results:
+
+
+
+
+
+ Detailed Report:
+
+ Pass: Your CCDA document has successfully passed our validation process. Congratulations! It complies with the
+ CCDA standards, ensuring its interoperability and correctness.
+
+
+ Warning: Your CCDA document has passed the basic validation, but there are some issues that need your attention.
+ Please review the warnings below and take necessary actions to enhance the quality of your document.
+
+
+ Fail: Unfortunately, your CCDA document did not pass the validation. It indicates significant issues that must
+ be resolved. Please review the errors below for detailed information on what needs to be corrected.
+
+
+
+ Results Total
+
+
+
+
+
+
+
+
+
+
+
+
+
+ C-CDA MDHT Conformance
+
+ )
+}
diff --git a/src/components/c-cda/validation/ValidationStatusIndicator.tsx b/src/components/c-cda/validation/ValidationStatusIndicator.tsx
new file mode 100644
index 00000000..335ecfe2
--- /dev/null
+++ b/src/components/c-cda/validation/ValidationStatusIndicator.tsx
@@ -0,0 +1,38 @@
+import React from 'react'
+import { Box, Typography, LinearProgress } from '@mui/material'
+
+type ValidationStatus = 'error' | 'warning' | 'pass'
+
+interface ValidationStatusIndicatorProps {
+ status: ValidationStatus
+}
+
+const ValidationStatusIndicator: React.FC = ({ status }) => {
+ const statusMap: { [key in ValidationStatus]: { color: string; value: number } } = {
+ error: { color: '#FF5252', value: 5 },
+ warning: { color: '#83380E', value: 50 },
+ pass: { color: '#122953', value: 100 },
+ }
+
+ const statusInfo = statusMap[status]
+
+ return (
+
+ Validation Status: {status.charAt(0).toUpperCase() + status.slice(1)}
+
+
+ )
+}
+
+export default ValidationStatusIndicator
diff --git a/src/components/c-cda/validation/ValidatorLoadingCard.tsx b/src/components/c-cda/validation/ValidatorLoadingCard.tsx
new file mode 100644
index 00000000..3d04b34f
--- /dev/null
+++ b/src/components/c-cda/validation/ValidatorLoadingCard.tsx
@@ -0,0 +1,93 @@
+import React, { useState, useEffect, FC } from 'react'
+import { Card, CardContent, Typography, IconButton, LinearProgress, Backdrop, Button } from '@mui/material'
+import CloseIcon from '@mui/icons-material/Close'
+import ValidatorResultsCard from './ValidatorResultsCard'
+
+interface ValidatorLoadingCardProps {
+ open: boolean
+ handleClose: () => void
+ onLoadingComplete: () => void
+}
+
+const ValidatorLoadingCard: FC = ({ open, handleClose, onLoadingComplete }) => {
+ const [progress, setProgress] = useState(0)
+
+ useEffect(() => {
+ if (open) {
+ setProgress(0)
+ const timer = setInterval(() => {
+ setProgress((prevProgress) => {
+ if (prevProgress >= 100) {
+ clearInterval(timer)
+ onLoadingComplete()
+ return 100
+ }
+ return prevProgress + 10
+ })
+ }, 300)
+
+ return () => {
+ clearInterval(timer)
+ }
+ } else {
+ setProgress(0)
+ }
+ }, [open, onLoadingComplete])
+
+ return (
+ theme.zIndex.drawer + 1 }} open={open}>
+
+
+
+
+
+
+ Your files are validating...
+
+ Estimate time: {Math.round((1 - progress / 100) * 3)} seconds
+
+
+ Don't close out this given tab or refresh the screen, if you do the validation will stop.
+
+
+
+
+ )
+}
+const ValidationComponent = () => {
+ const [validationOpen, setValidationOpen] = useState(false)
+ const [resultsOpen, setResultsOpen] = useState(false)
+
+ const handleLoadingComplete = () => {
+ setValidationOpen(false)
+ setResultsOpen(true)
+ }
+
+ return (
+ <>
+
+ setValidationOpen(false)}
+ onLoadingComplete={handleLoadingComplete}
+ />
+ setResultsOpen(false)} />
+
+ )
+}
+
+export default ValidationComponent
diff --git a/src/components/c-cda/validation/ValidatorResultsCard.tsx b/src/components/c-cda/validation/ValidatorResultsCard.tsx
new file mode 100644
index 00000000..1bcd2433
--- /dev/null
+++ b/src/components/c-cda/validation/ValidatorResultsCard.tsx
@@ -0,0 +1,92 @@
+import React, { FC, useRef } from 'react'
+import {
+ Backdrop,
+ Card,
+ IconButton,
+ Typography,
+ Accordion,
+ AccordionSummary,
+ AccordionDetails,
+ Button,
+ Box,
+ Divider,
+} from '@mui/material'
+import CloseIcon from '@mui/icons-material/Close'
+import ExpandMoreIcon from '@mui/icons-material/ExpandMore'
+import KeyboardArrowUpIcon from '@mui/icons-material/KeyboardArrowUp'
+import ValidatorResultsSummary from './ValidationResultsSummary'
+
+interface ValidatorResultsCardProps {
+ open: boolean
+ handleClose: () => void
+}
+
+const ValidatorResultsCard: FC = ({ open, handleClose }) => {
+ const handleBackToTop = () => {
+ if (mainContentRef.current) {
+ mainContentRef.current.scrollTop = 0
+ }
+ }
+
+ const mainContentRef = useRef(null)
+
+ return (
+ theme.zIndex.drawer + 1 }} open={open} onClick={handleClose}>
+ e.stopPropagation()}
+ >
+
+ Validation Results
+
+
+
+
+
+
+
+ Summary & Results
+
+
+ }>
+ S&CC Vocabulary Validation Conformance
+
+ {/* future accordion options */}
+
+
+
+ }>
+ S&CC Reference C-CDA Validation
+
+ {/* future accordion options */}
+
+
+ Original C-CDA
+
+
+
+
+
+
+
+
+
+ } onClick={handleBackToTop}>
+ Back to Top
+
+
+
+
+ )
+}
+
+export default ValidatorResultsCard
diff --git a/src/components/c-cda/validation/uscdi-v1/USCDIV1Validator.tsx b/src/components/c-cda/validation/uscdi-v1/USCDIV1Validator.tsx
new file mode 100644
index 00000000..f96eb8b5
--- /dev/null
+++ b/src/components/c-cda/validation/uscdi-v1/USCDIV1Validator.tsx
@@ -0,0 +1,39 @@
+'use client'
+import BannerBox from '@/components/shared/BannerBox'
+import styles from '@shared/styles.module.css'
+import Link from 'next/link'
+import TabsComponent, { TabInputs } from '@/components/shared/TabsComponent'
+import V1FullTab from './V1FullTab'
+import V1IGOnlyTab from './V1IGOnlyTab'
+
+export default function USCDIV1Validator() {
+ const uscdiV1Tabs: TabInputs[] = [
+ { tabName: 'VALIDATE YOUR C-CDA DOCUMENT', tabIndex: 0, tabPanel: },
+ { tabName: 'VALIDATE WITH THE C-CDA IMPLEMENTATION GUIDE ONLY', tabIndex: 1, tabPanel: },
+ ]
+ return (
+ <>
+
+ C-CDA
+ ,
+
+ USCDI V1 Validator
+ ,
+ ]}
+ heading={'C-CDA USCDI V1 Validator'}
+ // TODO: Get a unique description from the ONC for USCDI V1
+ description={
+ <>
+ The C-CDA R2.1 Validator is a tool used to check if electronic health documents comply with the Clinical
+ Document Architecture (C-CDA) standard's R2.1 version. C-CDA is a standardized format for sharing
+ clinical information, and the validator ensures that documents follow the correct format and content rules
+ before being exchanged between healthcare systems.
+
+ }
+ />
+
+
+ )
+}
diff --git a/src/components/c-cda/validation/uscdi-v1/V1FullTab.tsx b/src/components/c-cda/validation/uscdi-v1/V1FullTab.tsx
new file mode 100644
index 00000000..4ec60216
--- /dev/null
+++ b/src/components/c-cda/validation/uscdi-v1/V1FullTab.tsx
@@ -0,0 +1,6 @@
+import V3FullTab from '../uscdi-v3/V3FullTab'
+
+// TODO: Support unique functionality (API calls, select data, etc.), view should be the same
+export default function V1FullTab() {
+ return
+}
diff --git a/src/components/c-cda/validation/uscdi-v1/V1IGOnlyTab.tsx b/src/components/c-cda/validation/uscdi-v1/V1IGOnlyTab.tsx
new file mode 100644
index 00000000..e36bdf42
--- /dev/null
+++ b/src/components/c-cda/validation/uscdi-v1/V1IGOnlyTab.tsx
@@ -0,0 +1,6 @@
+import V3IGOnlyTab from '../uscdi-v3/V3IGOnlyTab'
+
+// TODO: Support unique functionality (API calls, select data, etc.), view should be the same
+export default function V1IGOnlyTab() {
+ return
+}
diff --git a/src/components/c-cda/validation/uscdi-v3/USCDIV3Validator.tsx b/src/components/c-cda/validation/uscdi-v3/USCDIV3Validator.tsx
new file mode 100644
index 00000000..141cd6c1
--- /dev/null
+++ b/src/components/c-cda/validation/uscdi-v3/USCDIV3Validator.tsx
@@ -0,0 +1,39 @@
+'use client'
+import BannerBox from '@/components/shared/BannerBox'
+import styles from '@shared/styles.module.css'
+import Link from 'next/link'
+import TabsComponent, { TabInputs } from '@/components/shared/TabsComponent'
+import V3FullTab from './V3FullTab'
+import V3IGOnlyTab from './V3IGOnlyTab'
+
+export default function USCDIV3Validator() {
+ const uscdiV3Tabs: TabInputs[] = [
+ { tabName: 'VALIDATE YOUR C-CDA DOCUMENT', tabIndex: 0, tabPanel: },
+ { tabName: 'VALIDATE WITH THE C-CDA IMPLEMENTATION GUIDE ONLY', tabIndex: 1, tabPanel: },
+ ]
+ return (
+ <>
+
+ C-CDA
+ ,
+
+ USCDI V3 Validator
+ ,
+ ]}
+ heading={'C-CDA USCDI V3 Validator'}
+ // TODO: Get a unique description from the ONC for USCDI V3
+ description={
+ <>
+ The C-CDA R2.1 Validator is a tool used to check if electronic health documents comply with the Clinical
+ Document Architecture (C-CDA) standard's R2.1 version. C-CDA is a standardized format for sharing
+ clinical information, and the validator ensures that documents follow the correct format and content rules
+ before being exchanged between healthcare systems.
+
+ }
+ />
+
+
+ )
+}
diff --git a/src/components/c-cda/validation/uscdi-v3/V3FullTab.tsx b/src/components/c-cda/validation/uscdi-v3/V3FullTab.tsx
new file mode 100644
index 00000000..09327dac
--- /dev/null
+++ b/src/components/c-cda/validation/uscdi-v3/V3FullTab.tsx
@@ -0,0 +1,160 @@
+import DragDropFileUpload from '@/components/shared/DragandDropFile'
+import {
+ Box,
+ Button,
+ Container,
+ Divider,
+ FormControl,
+ FormControlLabel,
+ FormLabel,
+ InputLabel,
+ MenuItem,
+ Radio,
+ RadioGroup,
+ Select,
+ SelectChangeEvent,
+ Typography,
+} from '@mui/material'
+import { useState } from 'react'
+import ValidationComponent from '../ValidatorLoadingCard'
+
+// TODO: Create a generic version of this to Support unique functionality
+// (API calls, select data, etc.) of different C-CDA validators without duplication
+export default function V3FullTab() {
+ const [criteriaOption, setCriteriaOption] = useState('')
+
+ const handleCriteriaChange = (e: SelectChangeEvent) => {
+ console.log('handleCriteriaChange(e), event: ' + e)
+ setCriteriaOption(e.target.value)
+ }
+
+ const criteriaOptions = [
+ {
+ value: '170.315_b1_ToC_Amb',
+ label: '170.315_b1_ToC_Amb',
+ },
+ {
+ value: 'etc. ...',
+ label: 'etc. ...',
+ },
+ ]
+
+ const [scenarioOption, setScenarioOption] = useState('')
+
+ const handleScenarioChange = (e: SelectChangeEvent) => {
+ console.log('handleScenarioChange(e), event: ' + e)
+ setScenarioOption(e.target.value)
+ }
+
+ const scenarioOptions = [
+ {
+ value: 'pdf1',
+ label: 'pdf1',
+ },
+ {
+ value: 'pdf2',
+ label: 'pdf2',
+ },
+ {
+ value: 'etc. ... this is fetched data',
+ label: 'etc. ... this is fetched data',
+ },
+ ]
+
+ const handleSubmit = (e: React.FormEvent) => {
+ console.log('handleSubmit(e), event: ' + e)
+ }
+
+ const handleSystemChange = (e: React.ChangeEvent) => {
+ console.log('handleSystemChange(e), event: ' + e)
+ }
+
+ return (
+
+ {/* Header */}
+
+
+ To validate your C-CDA document for USCDI V3:
+
+
+ {/* Sender or Receiver Selection */}
+
+
+ Select your system of C-CDA documents
+
+ } label="Sender" />
+ or
+ } label="Receiver" />
+
+
+
+
+ {/* Criteria Selection */}
+
+
+ Select validation criteria
+
+
+
+
+ {/* Scenario Selection */}
+
+
+ Select scenario file
+
+
+
+
+
+
+ {/* Upload */}
+
+
+ Upload your generated C-CDA file and submit for validation
+
+
+
+
+ {/* Buttons */}
+
+
+
+
+
+
+
+
+
+ )
+}
diff --git a/src/components/c-cda/validation/uscdi-v3/V3IGOnlyTab.tsx b/src/components/c-cda/validation/uscdi-v3/V3IGOnlyTab.tsx
new file mode 100644
index 00000000..d0a3db4d
--- /dev/null
+++ b/src/components/c-cda/validation/uscdi-v3/V3IGOnlyTab.tsx
@@ -0,0 +1,30 @@
+import DragDropFileUpload from '@/components/shared/DragandDropFile'
+import { Box, Button, Container, Typography } from '@mui/material'
+
+// TODO: Create a generic version of this to Support unique functionality
+// (API calls) of different C-CDA validators without duplication
+export default function V3IGOnlyTab() {
+ return (
+
+ {/* Header */}
+
+
+ To validate with the C-CDA Implementation Guide, attach or drag your C-CDA document and press Validate:
+
+
+ *Note: This validation alone is not used for certification
+
+
+
+ {/* Upload */}
+
+
+
+
+ {/* Validate */}
+
+
+
+
+ )
+}
diff --git a/src/components/cqm-qrda/CqmHome.tsx b/src/components/cqm-qrda/CqmHome.tsx
new file mode 100644
index 00000000..75d413f6
--- /dev/null
+++ b/src/components/cqm-qrda/CqmHome.tsx
@@ -0,0 +1,150 @@
+// MUI Imports
+import BannerBox from '../shared/BannerBox'
+import { Box, Container, Divider } from '@mui/material'
+// Global Imports
+import Link from 'next/link'
+// MUI Icons
+import GitHubIcon from '@mui/icons-material/GitHub'
+import LoginIcon from '@mui/icons-material/Login'
+import CardWithImage from '@shared/CardWithImage'
+import TrackChangesIcon from '@mui/icons-material/TrackChanges'
+import { ArrowForward } from '@mui/icons-material'
+import cypressKnowledgeBaseImagery from '@public/cqm-qrda/Cypress-Knowledge-Base1.svg'
+import cypressValidatorImagery from '@public/cqm-qrda/Cypress-QRDA-Validator.svg'
+// Styles
+import palette from '@/styles/palette'
+import SectionHeader from '../shared/SectionHeader'
+import VerticalCard from './VerticalCard'
+import CardWithBorder from '../shared/CardWithBorder'
+// Images
+const maxWidth: number = 320
+
+const CqmHome = () => {
+ return (
+
+ {/* Global Header */}
+
+ CQM-QRDA
+
+ }
+ heading={'CQM QRDA Testing'}
+ description={
+ <>
+ {
+ "Cypress, the official testing tool for EHR Certification under ONC's 2014 and 2015 Certification Editions, ensures precise evaluation of Clinical Quality Measures (CQM) in Electronic Health Records. Tailored for both EHR vendors and Authorized Testing Labs, Cypress, sponsored by the Office of the National Coordinator for Health IT and developed by The MITRE Corporation, facilitates rigorous and repeatable testing for accurate calculation of CQMs for Eligible Providers and Hospitals."
+ }
+
+ }
+ />
+ {/* Main Content */}
+
+ {/* Cypress Header*/}
+
+
+ {/* Cypress Content*/}
+
+ {/* Cypress Card With Images */}
+
+
+
+
+ {/* Vertical Cypress Resources */}
+
+ }
+ buttonHref={'https://cypressdemo.healthit.gov/'}
+ />
+ }
+ buttonHref={'https://github.com/projectcypress/cypress/wiki'}
+ />
+ }
+ buttonHref={'https://jira.oncprojectracking.org/browse/CYPRESSef'}
+ />
+
+
+
+ {/* Other Tools & Resources Header */}
+
+ {/* Other Tools & Resources Content */}
+
+ {/* Bonnie Card */}
+ }
+ />
+
+ {/* eCQI Resource CenterCard */}
+ }
+ />
+
+
+
+
+ )
+}
+
+export default CqmHome
diff --git a/src/components/cqm-qrda/VerticalCard.tsx b/src/components/cqm-qrda/VerticalCard.tsx
new file mode 100644
index 00000000..1be2840f
--- /dev/null
+++ b/src/components/cqm-qrda/VerticalCard.tsx
@@ -0,0 +1,36 @@
+import { Card, CardHeader, CardContent, Typography, Button } from '@mui/material'
+
+export interface VerticalCardProps {
+ title: string
+ description: string
+ buttonTitle: string
+ buttonIcon: React.ReactNode
+ buttonHref: string
+}
+const VerticalCard = ({ title, description, buttonTitle, buttonIcon, buttonHref }: VerticalCardProps) => {
+ return (
+
+
+
+ {description}
+
+
+
+ )
+}
+
+export default VerticalCard
diff --git a/src/components/direct/DirectHome.tsx b/src/components/direct/DirectHome.tsx
new file mode 100644
index 00000000..8cefb1ae
--- /dev/null
+++ b/src/components/direct/DirectHome.tsx
@@ -0,0 +1,184 @@
+import Box from '@mui/material/Box'
+import BannerBox from '@shared/BannerBox'
+import CriteriaCard from '@shared/CardWithImage'
+import b1 from '@public/direct/b1.svg'
+import h1 from '@public/direct/h1.svg'
+import h2 from '@public/direct/h2.svg'
+import { Container, Divider } from '@mui/material'
+import CategoryCard from '@shared/CardWithBorder'
+import CertificateCard from './shared/CertificateCard'
+import publicCert from '@public/direct/publicCert.svg'
+import trustAnchor from '@public/direct/trustAnchor.svg'
+import invalidTrustAnchor from '@public/direct/invalidTrustAnchor.svg'
+import rootCA from '@public/direct/rootCA.svg'
+import Link from 'next/link'
+import styles from '@shared/styles.module.css'
+import SectionHeader from '../shared/SectionHeader'
+import ArrowForwardIcon from '@mui/icons-material/ArrowForward'
+
+const DirectHome = () => {
+ const cardMaxWidth = 345
+ const cardImageWidth = '345px'
+ const flexibleBox = { display: 'flex', gap: 4, flexDirection: 'row', width: '100%', justifyContent: 'space-between' }
+ return (
+ <>
+ {/* Global Header */}
+
+ Direct
+
+ }
+ heading={'Direct Project Tooling'}
+ description={
+ <>
+ This area provides capabilities to validate your Direct implementation to applicable
+ standards-specifications. To verify basic Direct send capabilities of your system send a message to:
+
+
+ testing@ett.healthit.gov
+
+
+
+ }
+ />
+ {/* Main Content */}
+
+
+
+
+
+
+
+
+
+
+
+
+ }
+ />
+ }
+ />
+ }
+ />
+
+
+ }
+ />
+ }
+ />
+ }
+ />
+
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default DirectHome
diff --git a/src/components/direct/dcdt/DCDTCertificates.tsx b/src/components/direct/dcdt/DCDTCertificates.tsx
new file mode 100644
index 00000000..28d0e6bc
--- /dev/null
+++ b/src/components/direct/dcdt/DCDTCertificates.tsx
@@ -0,0 +1,157 @@
+'use client'
+import palette from '@/styles/palette'
+import { Typography, List, ListItem, Box, TextField, MenuItem, Button } from '@mui/material'
+import TestCasePanel from './TestCasePanel'
+import React, { useEffect, useState } from 'react'
+import _ from 'lodash'
+import Link from 'next/link'
+import discoverTestCases from './DiscoverTestCases'
+import bulletedList from '../shared/BulletList'
+
+const DCDTCertificates = () => {
+ const [discoverCase, setDiscoverCase] = React.useState(discoverTestCases.filter((c) => c.code === ' '))
+
+ const [openDiscoverCase, setOpenDiscoverCase] = React.useState(false)
+ const [directAddress, setDirectAddress] = useState('')
+ const [emailAddress, setEmailAddress] = useState('')
+
+ useEffect(() => {
+ if (discoverCase[0].code !== ' ') {
+ setOpenDiscoverCase(true)
+ } else {
+ setOpenDiscoverCase(false)
+ }
+ }, [discoverCase])
+
+ const handleDiscoverCaseSelect = (event: React.ChangeEvent) => {
+ const testCase = discoverTestCases.filter((c) => c.code === event.target.value)
+ setDiscoverCase(testCase)
+ }
+
+ const handleReset = () => {
+ setDiscoverCase(discoverTestCases.filter((c) => c.code === ' '))
+ setDirectAddress('')
+ setEmailAddress('')
+ }
+
+ const handleSubmit = () => {
+ //TO-DO
+ }
+
+ const handleChange = (e: React.ChangeEvent) => {
+ const { name, value } = e.target
+ if (_.isEqual(name, 'step2DirectAddress')) {
+ setDirectAddress(value)
+ }
+ if (_.isEqual(name, 'emailAddress')) {
+ setEmailAddress(value)
+ }
+ }
+
+ return (
+
+
+ Directions
+
+
+
+
+ {"Download the Testing Tool's trust anchor."} Download Trust Anchor
+
+
+
+
+ Upload the anchor to your Direct instance. This will allow you to send messages to our tool.
+
+
+
+
+ Using the form below, map the Direct email address from which you will be sending messages to a non-Direct
+ email address that will receive a regular email containing test results. This email address should be able
+ to receive plain text messages. Make sure you have access to the recipient email address in order to verify
+ the receipt of the messages.
+
+
+
+
+
+
+
+
+ {
+ 'Choose a test case from the drop down menu below. Read the test case description below the "Direct Address" field, copy the displayed Direct address and proceed to step 5. You should run all of the tests in order to verify that your system can correctly discover certificates in either DNS CERT records or LDAP servers. (Note: your system MUST NOT already contain a certificate for the address selected or the test case will not be valid).'
+ }
+
+
+
+
+ {
+ "Attempt to send a message to the Direct address that you've just copied. Please only send to one address at a time. The test case results message will indicate the test case results. See the test case instructions for additional information."
+ }
+
+
+
+
+ {discoverTestCases.map((option) => (
+
+ ))}
+
+ {openDiscoverCase && (
+ <>
+
+ Direct Address:
+ {discoverCase[0].Direct_address_2015}
+
+
+
+ )}
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default DCDTCertificates
diff --git a/src/components/direct/dcdt/DiscoverTestCases.tsx b/src/components/direct/dcdt/DiscoverTestCases.tsx
new file mode 100644
index 00000000..d105fb7a
--- /dev/null
+++ b/src/components/direct/dcdt/DiscoverTestCases.tsx
@@ -0,0 +1,548 @@
+import { TestCaseFields } from './TestCasePanel'
+
+const discoverTestCases: TestCaseFields[] = [
+ { code: ' ', name: '--No testcase selected--' },
+ {
+ code: 'D1_DNS_AB_Valid',
+ testcaseid: '1',
+ name: 'D1 - Valid address-bound certificate discovery in DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd1@domain1.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd1@domain1.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for address-bound CERT records and discover a valid address-bound X.509 certificate for a Direct address.',
+ RTM_Sections: '1, 3',
+ RFC_4398: 'Section 2.1',
+ Direct_SHT: 'Sections 4.0 and 5.3',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D1_valA',
+ Valid: 'true',
+ Description: 'Valid address-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd1@domain1.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ Background_Certificate: [
+ {
+ name: 'D1_invB',
+ Valid: 'false',
+ Description: 'Invalid domain-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'LDAP', Mail_Address: 'domain1.dcdt30prod.sitenv.org' }],
+ },
+ {
+ name: 'D1_invC',
+ Valid: 'false',
+ Description:
+ 'Invalid address-bound certificate for the Direct address in an LDAP server with an associated SRV record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd1@domain1.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ {
+ name: 'D1_invD',
+ Valid: 'false',
+ Description:
+ 'Invalid domain-bound certificate for the Direct address in an LDAP server with an associated SRV record.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'LDAP', Mail_Address: 'domain1.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ ],
+ },
+ {
+ code: 'D2_DNS_DB_Valid',
+ testcaseid: '2',
+ name: 'D2 - Valid domain-bound certificate discovery in DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd2@domain1.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd2@domain1.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for domain-bound CERT records and discover a valid domain-bound X.509 certificate for a Direct address.',
+ RTM_Sections: '1, 3',
+ RFC_4398: 'Section 2.1',
+ Direct_SHT: 'Direct Applicability Statement for Secure Health Transport: Sections 4.0 and 5.3',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D2_valB',
+ Valid: 'true',
+ Description:
+ 'Valid domain-bound certificate in a DNS CERT record containing the Direct address in the rfc822Name of the SubjectAlternativeName extension.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'DNS', Mail_Address: 'domain1.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ Background_Certificate: [
+ {
+ name: 'D2_invC',
+ Valid: 'false',
+ Description:
+ 'Invalid address-bound certificate for the Direct address in an LDAP server with an associated SRV record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd2@domain1.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ {
+ name: 'D1_invD',
+ Valid: 'false',
+ Description:
+ 'Invalid domain-bound certificate for the Direct address in an LDAP server with an associated SRV record.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'LDAP', Mail_Address: 'domain1.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ ],
+ },
+ {
+ code: 'D3_LDAP_AB_Valid',
+ testcaseid: '3',
+ name: 'D3 - Valid address-bound certificate discovery in LDAP',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd3@domain2.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd3@domain2.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for SRV records and discover a valid address-bound X.509 certificate for a Direct address in the associated LDAP server.',
+ RTM_Sections: '2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22',
+ RFC_2798: 'Section 9.1.2',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D3_valC',
+ Valid: 'true',
+ Description:
+ 'Valid address-bound certificate in an LDAP server with the appropriate mail attribute and InetOrgPerson schema. The associated SRV record has Priority = 0.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd3@domain2.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ ],
+ Background_Certificate: [
+ {
+ name: 'D3_invD',
+ Valid: 'false',
+ Description:
+ 'Invalid domain-bound certificate for the Direct address in an LDAP server with an associated SRV record',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'LDAP', Mail_Address: 'domain2.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ ],
+ },
+ {
+ code: 'D4_LDAP_DB_Valid',
+ testcaseid: '4',
+ name: 'D4 - Valid domain-bound certificate discovery in LDAP',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd4@domain2.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd4@domain2.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for SRV records and discover a valid domain-bound X.509 certificate for a Direct address in the associated LDAP server.',
+ RTM_Sections: '2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22',
+ RFC_2798: 'Section 9.1.2',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D4_valD',
+ Valid: 'true',
+ Description:
+ 'Valid domain-bound certificate in an LDAP server with the appropriate mail attribute and InetOrgPerson schema. The associated SRV record has Priority = 0.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'LDAP', Mail_Address: 'domain2.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ ],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D5_DNS_AB_Invalid',
+ testcaseid: '5',
+ name: 'D5 - Invalid address-bound certificate discovery in DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd5@domain1.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd5@domain1.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for address-bound CERT records and finds, but does not select the associated invalid address-bound X.509 certificate.',
+ RTM_Sections: '1, 3',
+ Instructions:
+ 'Verify that your system did NOT send an email because it could not find a certificate for the Direct address. To pass this test case, you must NOT receive an email in response.',
+ Target_Certificate: [
+ {
+ name: 'D5_invA',
+ Valid: 'false',
+ Description: 'An invalid address-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd5@domain1.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D6_DNS_DB_Invalid',
+ testcaseid: '6',
+ name: 'D6 - Invalid domain-bound certificate discovery in DNS',
+ Negative: 'true',
+ Optional: 'false',
+ Direct_address_2014: 'd6@domain4.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd6@domain4.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for domain-bound CERT records and finds, but does not select the associated invalid domain-bound X.509 certificate.',
+ RTM_Sections: '1, 3',
+ Instructions:
+ 'Verify that your system did NOT send an email because it could not find a certificate for the Direct address. To pass this test case, you must NOT receive an email in response.',
+ Target_Certificate: [
+ {
+ name: 'D6_invB',
+ Valid: 'false',
+ Description: 'An invalid domain-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'DNS', Mail_Address: 'domain4.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D7_LDAP_AB_Invalid',
+ testcaseid: '7',
+ name: 'D7 - Invalid address-bound certificate discovery in LDAP',
+ Negative: 'true',
+ Optional: 'false',
+ Direct_address_2014: 'd7@domain2.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd7@domain2.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for SRV records and finds, but does not select the invalid address-bound X.509 certificate in the associated LDAP server.',
+ RTM_Sections: '3, 22',
+ Instructions:
+ 'Verify that your system did NOT send an email because it could not find a certificate for the Direct address. To pass this test case, you must NOT receive an email in response.',
+ Target_Certificate: [
+ {
+ name: 'D7_invC',
+ Valid: 'true',
+ Description:
+ 'Invalid address-bound certificate for the Direct address in an LDAP server with an associated SRV record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd7@domain2.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ ],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D8_LDAP_DB_Invalid',
+ testcaseid: '8',
+ name: 'D8 - Invalid domain-bound certificate discovery in LDAP',
+ Negative: 'true',
+ Optional: 'false',
+ Direct_address_2014: 'd8@domain5.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd8@domain5.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for SRV records and finds, but does not select the invalid domain-bound X.509 certificate in the associated LDAP server.',
+ RTM_Sections: ' 3, 22',
+ Instructions:
+ 'Verify that your system did NOT send an email because it could not find a certificate for the Direct address. To pass this test case, you must NOT receive an email in response.',
+ Target_Certificate: [
+ {
+ name: 'D8_invD',
+ Valid: 'false',
+ Description:
+ ' Invalid domain-bound certificate for the Direct address in an LDAP server with an associated SRV record.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'LDAP', Mail_Address: 'domain5.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '12389' }],
+ },
+ ],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D9_DNS_AB_SelectValid',
+ testcaseid: '9',
+ name: 'D9 - Select valid address-bound certificate over invalid certificate in DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd9@domain1.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd9@domain1.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for address-bound CERT records and select the valid address-bound X.509 certificate instead of the invalid address-bound X.509 certificate.',
+ RTM_Sections: '1, 3',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D9_valA',
+ Valid: 'true',
+ Description:
+ 'Valid address-bound certificate in a DNS CERT record containing the Direct address in the rfc822Name of the SubjectAlternativeName extension.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd9@domain1.dcdt30prod.sitenv.org' }],
+ },
+ {
+ name: 'D9_invA',
+ Valid: 'false',
+ Description: 'Invalid address-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd9@domain1.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D10_LDAP_AB_UnavailableLDAPServer',
+ testcaseid: '10',
+ name: 'D10 - Certificate discovery in LDAP with one unavailable LDAP server',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd10@domain3.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd10@domain3.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for SRV records and attempts to connect to an LDAP server based on the priority value specified in the SRV records until a successful connection is made. Your system should first attempt to connect to an LDAP server associated with an SRV record containing the lowest priority value (highest priority). Since this LDAP server is unavailable, your system should then attempt to connect to the LDAP server associated with an SRV record containing the second lowest priority value (second highest priority) and discover the valid address-bound X.509 certificate in the available LDAP server.',
+ RTM_Sections: ' 15, 18',
+ RFC_2782: 'Page 3, Priority Section',
+ Direct_SHT: 'Direct Applicability Statement for Secure Health Transport: Sections 4.0 and 5.3',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D10_valE',
+ Valid: 'true',
+ Description:
+ 'Valid address-bound certificate in an LDAP server with the appropriate mail attribute and InetOrgPerson schema. The associated SRV record has Priority = 1.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd10@domain3.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '11389' }],
+ },
+ ],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D11_DNS_NB_NoDNSCertsorSRV',
+ testcaseid: '11',
+ name: 'D11 - No certificates discovered in DNS CERT records and no SRV records',
+ Negative: 'true',
+ Optional: 'false',
+ Direct_address_2014: 'd11@domain6.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd11@domain6.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system does not find any certificates when querying DNS for CERT records and does not find any SRV records in DNS.',
+ RTM_Sections: '1, 3, 18',
+ Instructions:
+ 'Verify that your system did NOT send an email because it could not find a certificate for the Direct address. To pass this test case, you must NOT receive an email in response.',
+ Target_Certificate: [],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D12_LDAP_NB_UnavailableLDAPServer',
+ testcaseid: '12',
+ name: 'D12 - No certificates found in DNS CERT records and no available LDAP servers',
+ Negative: 'true',
+ Optional: 'false',
+ Direct_address_2014: 'd12@domain7.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd12@domain7.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for SRV records and attempts to connect to an LDAP server associated with the only SRV record that should be found. Since this LDAP server is unavailable or does not exist and no additional SRV records should have been found, your system should not discover any X.509 certificates in either DNS CERT records or LDAP servers.',
+ RTM_Sections: '1, 3, 18',
+ Instructions:
+ 'Verify that your system did NOT send an email because it could not find a certificate for the Direct address. To pass this test case, you must NOT receive an email in response.',
+ Target_Certificate: [],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D13_LDAP_NB_NoCerts',
+ testcaseid: '13',
+ name: 'D13 - No certificates discovered in DNS CERT records or LDAP servers',
+ Negative: 'true',
+ Optional: 'false',
+ Direct_address_2014: 'd13@domain8.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd13@domain8.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system does not discover any certificates in DNS CERT records or LDAP servers when no certificates should be found.',
+ RTM_Sections: '1, 3, 18',
+ Instructions:
+ 'Verify that your system did NOT send an email because it could not find a certificate for the Direct address. To pass this test case, you must NOT receive an email in response.',
+ Target_Certificate: [],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D14_DNS_AB_TCPLargeCert',
+ testcaseid: '14',
+ name: 'D14 - Discovery of certificate larger than 512 bytes in DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd14@domain1.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd14@domain1.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for address-bound CERT records and discover a valid address-bound X.509 certificate that is larger than 512 bytes using a TCP connection.',
+ RTM_Sections: '1, 3, 4',
+ RFC_1035: 'Section 4.2',
+ RFC_4298: 'Section 4',
+ Direct_SHT: 'Direct Applicability Statement for Secure Health Transport: Section 5.4',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D14_valA',
+ Valid: 'true',
+ Description:
+ 'Valid address-bound certificate that is larger than 512 bytes in a DNS CERT record containing the Direct address in the rfc822Name of the SubjectAlternativeName extension.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd14@domain1.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ Background_Certificate: [],
+ },
+ {
+ code: 'D15_LDAP_AB_SRVPriority',
+ testcaseid: '15',
+ name: 'D15 - Certificate discovery in LDAP based on SRV priority value',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd15@domain2.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd15@domain2.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for SRV records and discover a valid address-bound X.509 certificate in the LDAP server associated with an SRV record containing the lowest priority value (highest priority).',
+ RTM_Sections: '15, 18',
+ RFC_2782: 'Page 3, Priority Section',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D15_valC',
+ Valid: 'true',
+ Description:
+ 'Valid address-bound certificate in an LDAP server with the appropriate mail attribute and InetOrgPerson schema. The associated SRV record has Priority = 0.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd15@domain2.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ ],
+ Background_Certificate: [
+ {
+ name: 'D15_invE',
+ Valid: 'false',
+ Description:
+ 'Invalid address-bound certificate for the Direct address in an LDAP server. The associated SRV record has Priority = 1.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd15@domain2.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '11389' }],
+ },
+ ],
+ },
+ {
+ code: 'D16_LDAP_AB_SRVWeight',
+ testcaseid: '16',
+ name: 'D16 - Certificate discovery in LDAP based on SRV weight value',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd16@domain5.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd16@domain5.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for SRV records and discover a valid address-bound X.509 certificate in the LDAP server associated with an SRV record containing the lowest priority value (highest priority) and the highest weight value when SRV records with the same priority value exist.',
+ RTM_Sections: '16, 18',
+ RFC_2782: 'Page 3, Weight Section',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D16_valC',
+ Valid: 'true',
+ Description:
+ 'Valid address-bound certificate in an LDAP server with the appropriate mail attribute and InetOrgPerson schema. The associated SRV record has Priority = 0 and Weight = 100.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd16@domain5.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '12389' }],
+ },
+ ],
+ Background_Certificate: [
+ {
+ name: 'D16_valE',
+ Valid: 'true',
+ Description:
+ 'Valid address-bound certificate in an LDAP server with the appropriate mail attribute and InetOrgPerson schema. The associated SRV record has Priority = 0 and Weight = 0.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'LDAP', Mail_Address: 'd16@domain5.dcdt30prod.sitenv.org', Host: '0.0.0.0', Port: '10389' }],
+ },
+ ],
+ },
+ {
+ code: 'D17_DNS_AB_CRLRevocation',
+ testcaseid: '17',
+ name: 'D17 - CRL-based revocation checking for address-bound certificate discovery in DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd17@domain9.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd17@domain9.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for address-bound CERT records and discover a valid X.509 certificate whose CRL-based revocation status indicates that it has not been revoked.',
+ RTM_Sections: '1, 3',
+ RFC_4398: 'Section 2.1',
+ Direct_SHT: 'Direct Applicability Statement for Secure Health Transport: Sections 4.0 and 5.3',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D17_valA',
+ Valid: 'true',
+ Description: 'Valid, non-revoked address-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd17@domain9.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ Background_Certificate: [
+ {
+ name: 'D17_invB',
+ Valid: 'false',
+ Description: 'An invalid, revoked address-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd17@domain9.dcdt30prod.sitenv.org' }],
+ },
+ {
+ name: 'D17_invC',
+ Valid: 'false',
+ Description: ' An invalid, revoked address-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd17@domain9.dcdt30prod.sitenv.org' }],
+ },
+ {
+ name: 'D17_invD',
+ Valid: 'false',
+ Description: 'Invalid domain-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'DNS', Mail_Address: 'domain9.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ },
+ {
+ code: 'D18_DNS_AB_AIAIntermediateIssuer',
+ testcaseid: '18',
+ name: 'D18 - AIA-based intermediate issuer certificate retrieval for address-bound certificate discovery in DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Direct_address_2014: 'd18@domain10.dcdt30prod.sitenv.org',
+ Direct_address_2015: 'd18@domain10.dcdt31prod.sitenv.org',
+ Description:
+ 'This test case verifies that your system can query DNS for an address-bound CERT record and discover a valid X.509 certificate whose path to the trusted root CA certificate must be retrieved via Authority Information Access (AIA) X.509v3 extension caIssuers HTTP URIs.',
+ RTM_Sections: '1, 3',
+ RFC_5280: 'Section 4.2.2.1',
+ Direct_SHT: 'Direct Applicability Statement for Secure Health Transport: Section 4.2.2',
+ Instructions:
+ 'You should have received an email indicating the test case results for your system. Examine the results to see if your system passed the test case. If you do not receive a message for the test case, then you should assume that the test case failed.',
+ Target_Certificate: [
+ {
+ name: 'D18_valA',
+ Valid: 'true',
+ Description:
+ 'Valid address-bound certificate issued by an intermediate CA for the Direct address in a DNS CERT record.',
+ Binding_Type: 'ADDRESS',
+ Location: [{ Type: 'DNS', Mail_Address: 'd18@domain10.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ Background_Certificate: [
+ {
+ name: 'D18_invB',
+ Valid: 'true',
+ Description: 'Invalid domain-bound certificate for the Direct address in a DNS CERT record.',
+ Binding_Type: 'DOMAIN',
+ Location: [{ Type: 'DNS', Mail_Address: 'domain10.dcdt30prod.sitenv.org' }],
+ },
+ ],
+ },
+]
+
+export default discoverTestCases
diff --git a/src/components/direct/dcdt/DiscoveryTool.tsx b/src/components/direct/dcdt/DiscoveryTool.tsx
new file mode 100644
index 00000000..8379f830
--- /dev/null
+++ b/src/components/direct/dcdt/DiscoveryTool.tsx
@@ -0,0 +1,155 @@
+import BannerBox from '@/components/shared/BannerBox'
+import Link from 'next/link'
+import styles from '@/components/shared/styles.module.css'
+import SubMenu, { menuProps } from '@/components/shared/SubMenu'
+import {
+ Container,
+ Box,
+ Card,
+ CardContent,
+ CardHeader,
+ Divider,
+ Typography,
+ List,
+ ListItem,
+ Button,
+} from '@mui/material'
+import palette from '@/styles/palette'
+import Hosting from './Hosting'
+import DCDTCertificates from './DCDTCertificates'
+import bulletedList from '../shared/BulletList'
+
+const menuItems: menuProps[] = [
+ { heading: 'Overview', href: '#overview' },
+ { heading: 'Hosting', href: '#hosting' },
+ { heading: "Discover DCDT's Certificates", href: '#certificates' },
+ { heading: 'Resources', href: '#resources' },
+]
+
+type LinkButtonProps = {
+ href: string
+ title: string
+}
+const LinkButton = ({ href, title }: LinkButtonProps) => {
+ return (
+
+
+
+ )
+}
+const DiscoveryTool = () => {
+ return (
+ <>
+ {/* Header */}
+
+ Direct
+ ,
+
+ Discovery Tool
+ ,
+ ]}
+ heading={'2015 Direct Certificate Discovery Tool'}
+ description={
+ <>
+ The 2015 Direct Certificate Discovery Tool (DCDT) was created to support automated testing of systems that
+ plan to enact the Certificate Discovery and Provider Directory Implementation Guide, approved as normative
+ specification by the Direct community, as of July 9, 2012. It is based on the written test package and
+ requirement traceability matrix created by the Modular Specifications project under the direction of the
+ Office of the National Coordinator (ONC) and National Institute of Standards and Technology (NIST).
+
+ }
+ />
+ {/* Main Content */}
+
+
+
+
+ {/* Overview */}
+
+
+
+
+
+ The tool is divided into two main testing areas:
+
+
+
+
+ Hosting allows a System Under Test (SUT) to verify that their certificates are hosted correctly,
+ and discoverable by other Direct implementations.
+
+
+
+
+ Discovery allows a SUT to verify that they can discover certificates in other Direct
+ implementations by using them to send Direct messages.
+
+
+
+
+
+ Get information on how to report bugs, seek technical support, or contact our customer service team.
+
+
+
+ {/* Hosting */}
+
+
+
+
+
+
+
+ {/* Discover DCDT's Certificates */}
+
+
+
+
+
+
+
+ {/* Resources */}
+
+
+
+
+
+ Direct Reference Information
+
+
+
+
+
+
+
+ DCDT Information
+
+
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default DiscoveryTool
diff --git a/src/components/direct/dcdt/Hosting.tsx b/src/components/direct/dcdt/Hosting.tsx
new file mode 100644
index 00000000..27bfe2ed
--- /dev/null
+++ b/src/components/direct/dcdt/Hosting.tsx
@@ -0,0 +1,108 @@
+'use client'
+import palette from '@/styles/palette'
+import { Typography, List, ListItem, Box, TextField, MenuItem, Button } from '@mui/material'
+import TestCasePanel from './TestCasePanel'
+import React, { useEffect, useState } from 'react'
+import hostingTestCases from './HostingTestCases'
+import bulletedList from '../shared/BulletList'
+
+const Hosting = () => {
+ const [hostingCase, setHostingCase] = useState(hostingTestCases.filter((c) => c.code === ' '))
+ const [openHostingCase, setOpenHostingCase] = useState(false)
+ const [hostingDirectAddress, setHostingDirectAddress] = useState('')
+
+ useEffect(() => {
+ if (hostingCase[0].code !== ' ') {
+ setOpenHostingCase(true)
+ } else {
+ setOpenHostingCase(false)
+ }
+ }, [hostingCase])
+
+ const handleHostingCaseSelect = (event: React.ChangeEvent) => {
+ const testCase = hostingTestCases.filter((c) => c.code === event.target.value)
+ setHostingCase(testCase)
+ }
+
+ const handleReset = () => {
+ setHostingCase(hostingTestCases.filter((c) => c.code === ' '))
+ setHostingDirectAddress('')
+ }
+ const handleSubmit = () => {
+ //To-DO
+ }
+
+ const handleChange = (e: React.ChangeEvent) => {
+ const { value } = e.target
+ setHostingDirectAddress(value)
+ }
+ return (
+ <>
+
+ Directions
+
+
+
+
+ Determine the required test cases for your SUT (System Under Test). Notice that there are two options for
+ storage of address-bound and domain-bound certificates.
+
+
+
+ Select a test case that reflects the SUT from the dropdown.
+
+
+
+ Read the Description and Instructions for the selected test case. Then enter the Direct address and submit.
+ Your SUT configuration may require that you select more than one test case. If so, then select one test case
+ at a time, following the instructions to execute the test after each selection.
+
+
+
+
+
+ {hostingTestCases.map((option) => (
+
+ ))}
+
+ {openHostingCase && }
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default Hosting
diff --git a/src/components/direct/dcdt/HostingTestCases.tsx b/src/components/direct/dcdt/HostingTestCases.tsx
new file mode 100644
index 00000000..c138416b
--- /dev/null
+++ b/src/components/direct/dcdt/HostingTestCases.tsx
@@ -0,0 +1,65 @@
+import { TestCaseFields } from './TestCasePanel'
+
+const hostingTestCases: TestCaseFields[] = [
+ { code: ' ', name: '--No testcase selected--' },
+ {
+ code: 'H1_DNS_AB_Normal',
+ name: 'H1 - Normal address-bound certificate search in DNS',
+ Binding_Type: 'ADDRESS',
+ Location_Type: 'DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Description:
+ "This test case verifies that your system's DNS can host and return the expected address-bound X.509 certificate.",
+ RTM_Sections: '1, 3',
+ RFC_4398: 'Section 2.1',
+ Direct_SHT: 'Section 5.3',
+ Instructions:
+ "Enter a Direct address corresponding to an address-bound X.509 certificate that is hosted by your system's DNS and then click Submit. DCDT will attempt to discover the certificate and display the result on the screen.",
+ },
+ {
+ code: 'H2_DNS_DB_Normal',
+ name: 'H2 - Normal domain-bound certificate search in DNS',
+ Binding_Type: 'DOMAIN',
+ Location_Type: 'DNS',
+ Negative: 'false',
+ Optional: 'false',
+ Description:
+ "This test case verifies that your system's DNS can host and return the expected domain-bound X.509 certificate.",
+ RTM_Sections: '1, 3',
+ RFC_4398: 'Section 2.1',
+ Direct_SHT: 'Section 5.3',
+ Instructions:
+ "Enter a Direct address corresponding to a domain-bound X.509 certificate that is hosted by your system's DNS and then click Submit. DCDT will attempt to discover the certificate and display the result on the screen.",
+ },
+ {
+ code: 'H3_LDAP_AB_Normal',
+ name: 'H3 - Normal address-bound certificate search in LDAP',
+ Binding_Type: 'ADDRESS',
+ Location_Type: 'LDAP',
+ Negative: 'false',
+ Optional: 'false',
+ Description:
+ "This test case verifies that your system's LDAP server can host and return the expected address-bound X.509 certificate.",
+ RTM_Sections: '2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22',
+ RFC_2798: 'Section 9.1.2',
+ Instructions:
+ "Enter a Direct address corresponding to an address-bound X.509 certificate that is hosted by your system's LDAP server and then click Submit. DCDT will attempt to discover the certificate and display the result on the screen.",
+ },
+ {
+ code: 'H4_LDAP_DB_Normal',
+ name: 'H4 - Normal domain-bound certificate search in LDAP',
+ Binding_Type: 'DOMAIN',
+ Location_Type: 'LDAP',
+ Negative: 'false',
+ Optional: 'false',
+ Description:
+ "This test case verifies that your system's LDAP server can host and return the expected domain-bound X.509 certificate.",
+ RTM_Sections: '2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22',
+ RFC_2798: 'Section 9.1.2',
+ Instructions:
+ "Enter a Direct address corresponding to a domain-bound X.509 certificate that is hosted by your system's LDAP server and then click Submit. DCDT will attempt to discover the certificate and display the result on the screen.",
+ },
+]
+
+export default hostingTestCases
diff --git a/src/components/direct/dcdt/TestCasePanel.tsx b/src/components/direct/dcdt/TestCasePanel.tsx
new file mode 100644
index 00000000..5ccc85fc
--- /dev/null
+++ b/src/components/direct/dcdt/TestCasePanel.tsx
@@ -0,0 +1,232 @@
+import palette from '@/styles/palette'
+import { Box, List, ListItem, Typography } from '@mui/material'
+import _ from 'lodash'
+import bulletedList from '../shared/BulletList'
+
+const oneColumnContainer = {
+ display: 'flex',
+ width: '100%',
+ flexDirection: 'column',
+ marginBottom: '8px',
+ marginLeft: '16px',
+ gap: 1,
+}
+
+const twoColumnContainer = {
+ display: 'flex',
+ width: '100%',
+ flexDirection: 'row',
+ marginBottom: 1,
+ marginLeft: 2,
+}
+export type LocationFields = {
+ Type?: string
+ Mail_Address?: string
+ Host?: string
+ Port?: string
+}
+export type CertificateFields = {
+ name: string
+ Valid: string
+ Description: string
+ Binding_Type: string
+ Location: LocationFields[] | []
+}
+export type TestCaseFields = {
+ code?: string
+ name?: string
+ testcaseid?: string
+ Direct_address_2014?: string
+ Direct_address_2015?: string
+ Binding_Type?: string
+ Location_Type?: string
+ Negative?: string
+ Optional?: string
+ Description?: string
+ RTM_Sections?: string
+ RFC_4398?: string
+ RFC_2782?: string
+ RFC_2798?: string
+ RFC_1035?: string
+ RFC_4298?: string
+ RFC_5280?: string
+ Direct_SHT?: string
+ Instructions?: string
+ Target_Certificate?: CertificateFields[]
+ Background_Certificate?: CertificateFields[]
+}
+
+export interface TestCasePanelProps {
+ testCaseFields: TestCaseFields[]
+}
+interface CertificateListProps {
+ certificateFields: CertificateFields[] | []
+}
+interface ListFields {
+ name: string
+ value: string
+}
+const CustomListItem = ({ name, value }: ListFields) => {
+ return (
+ <>
+
+
+ {name}:
+ {value}
+
+
+
+ )
+}
+const CertificateList = ({ certificateFields }: CertificateListProps) => {
+ return (
+ <>
+ {certificateFields.map((c, i) => {
+ return (
+
+ {_.has(c, 'name') && }
+
+ {_.has(c, 'Valid') && }
+ {_.has(c, 'Binding_Type') && }
+ {_.has(c, 'Location') && (
+ <>
+
+ {c.Location.map((l, i) => {
+ return (
+
+ {_.has(l, 'Type') && }
+ {_.has(l, 'Mail_Address') && (
+
+ )}
+ {_.has(l, 'Host') && }
+ {_.has(l, 'Port') && }
+
+ )
+ })}
+
+ )}
+ {_.has(c, 'Description') && }
+
+
+ )
+ })}
+
+ )
+}
+const TestCasePanel = ({ testCaseFields }: TestCasePanelProps) => {
+ return (
+
+
+
+ {_.has(testCaseFields[0], 'Binding_Type') && (
+
+ Binding Type:
+ {testCaseFields[0].Binding_Type}
+
+ )}
+
+ {_.has(testCaseFields[0], 'Location_Type') && (
+
+ Location Type:
+ {testCaseFields[0].Location_Type}
+
+ )}
+
+
+
+ {_.has(testCaseFields[0], 'Negative') && (
+
+ Negative:
+ {testCaseFields[0].Negative}
+
+ )}
+
+ {_.has(testCaseFields[0], 'Optional') && (
+
+ Optional:
+ {testCaseFields[0].Optional}
+
+ )}
+
+
+ {_.has(testCaseFields[0], 'RTM_Sections') && (
+
+ RTM Sections:
+ {testCaseFields[0].RTM_Sections}
+
+ )}
+ {_.has(testCaseFields[0], 'Description') && (
+
+ Description:
+ {testCaseFields[0].Description}
+
+ )}
+
+
+
+ Underlying Specification References:
+
+
+ {_.has(testCaseFields[0], 'RFC_4398') && (
+
+ )}
+
+ {_.has(testCaseFields[0], 'RFC_2782') && (
+
+ )}
+
+ {_.has(testCaseFields[0], 'RFC_2798') && (
+
+ )}
+
+ {_.has(testCaseFields[0], 'RFC_1035') && (
+
+ )}
+ {_.has(testCaseFields[0], 'RFC_4298') && (
+
+ )}
+ {_.has(testCaseFields[0], 'RFC_5280') && (
+
+ )}
+
+ {_.has(testCaseFields[0], 'Direct_SHT') && (
+
+ )}
+
+
+
+ {_.has(testCaseFields[0], 'Instructions') && (
+
+ Instructions:
+ {testCaseFields[0].Instructions}
+
+ )}
+ {_.has(testCaseFields[0], 'Target_Certificate') && (
+
+
+ Target Certificate(s)
+
+
+
+ )}
+ {_.has(testCaseFields[0], 'Background_Certificate') && (
+
+
+ Background Certificate(s)
+
+
+
+ )}
+
+
+ )
+}
+
+export default TestCasePanel
diff --git a/src/components/direct/hisp/HISPPortal.tsx b/src/components/direct/hisp/HISPPortal.tsx
new file mode 100644
index 00000000..83f6c73e
--- /dev/null
+++ b/src/components/direct/hisp/HISPPortal.tsx
@@ -0,0 +1,49 @@
+'use client'
+import BannerBox from '@/components/shared/BannerBox'
+import Link from 'next/link'
+import styles from '@shared/styles.module.css'
+import TabsComponent, { TabInputs } from '@/components/shared/TabsComponent'
+import SMTP from './SMTPTab'
+import MessageTracking from './MessageTrackingTab'
+import IMAP from './IMAPTab'
+import POP3 from './POP3Tab'
+import XDR from './XDRTab'
+import ValidationResults from './ValidationResultsTab'
+
+const HISPPortal = () => {
+ const hispTabs: TabInputs[] = [
+ { tabName: 'SMTP', tabIndex: 0, tabPanel: },
+ { tabName: 'MESSAGE TRACKING', tabIndex: 1, tabPanel: },
+ { tabName: 'IMAP', tabIndex: 2, tabPanel: },
+ { tabName: 'POP3', tabIndex: 3, tabPanel: },
+ { tabName: 'XDR', tabIndex: 4, tabPanel: },
+ { tabName: 'VALIDATION RESULTS', tabIndex: 5, tabPanel: },
+ ]
+ return (
+ <>
+ {/* Global Header */}
+
+ Direct
+ ,
+
+ HISP Testing Tools
+ ,
+ ]}
+ heading={'HISP Testing Tools '}
+ description={
+ <>
+ {
+ 'Software designed to evaluate and ensure the interoperability and security of health information exchange(HIE) systems. These tools are essential for testing the capabilities of HISPs, which are responsible for securely transmitting health information between different entities in the healthcare ecosystem, such as healthcare providers, laboratories, and public health agencies.'
+ }
+
+ }
+ />
+ {/* Main Content */}
+
+
+ )
+}
+
+export default HISPPortal
diff --git a/src/components/direct/hisp/IMAPTab.tsx b/src/components/direct/hisp/IMAPTab.tsx
new file mode 100644
index 00000000..ddc7e874
--- /dev/null
+++ b/src/components/direct/hisp/IMAPTab.tsx
@@ -0,0 +1,112 @@
+import {
+ Box,
+ Card,
+ CardContent,
+ Container,
+ FormControl,
+ InputLabel,
+ MenuItem,
+ Select,
+ SelectChangeEvent,
+ Typography,
+} from '@mui/material'
+import Profile from '../shared/Profile'
+import TestCard from './TestCard'
+import palette from '@/styles/palette'
+import * as React from 'react'
+import testCases from './data/SMTPTestCases'
+import _ from 'lodash'
+import TestFilter from './TestFilter'
+
+const IMAP = () => {
+ const [option, setOption] = React.useState('')
+ const imapTestCases = testCases.tests.filter((test) => test.protocol === 'imap')
+ const imapTestCasesSender = imapTestCases.filter((test) => test.sutRole === 'sender' && test.sutHisp)
+ const imapTestCasesReceiver = imapTestCases.filter((test) => test.sutRole === 'receiver' && test.sutHisp)
+ const handleChange = (event: SelectChangeEvent) => {
+ setOption(event.target.value as string)
+ }
+
+ const dropdown = [
+ {
+ value: 'sender',
+ label: 'Sender',
+ },
+ {
+ value: 'receiver',
+ label: 'Receiver',
+ },
+ ]
+
+ return (
+
+
+
+ Select sender or receiver for your system & fill in the additional fields to get started.{' '}
+
+
+
+
+
+
+
+
+
+ Choose your system as Sender or Receiver
+
+
+
+
+
+
+
+
+
+
+
+ {option !== '' && (
+
+
+
+ )}
+ {option === 'sender' && (
+
+ )}
+
+
+
+ )
+}
+
+export default XDR
diff --git a/src/components/direct/hisp/XDRTestCard.tsx b/src/components/direct/hisp/XDRTestCard.tsx
new file mode 100644
index 00000000..172975bf
--- /dev/null
+++ b/src/components/direct/hisp/XDRTestCard.tsx
@@ -0,0 +1,181 @@
+import {
+ Box,
+ Button,
+ Card,
+ CardContent,
+ CardHeader,
+ Divider,
+ TextField,
+ Typography,
+ FormControl,
+ FormHelperText,
+} from '@mui/material'
+
+import ContentPasteGoIcon from '@mui/icons-material/ContentPasteGo'
+import _ from 'lodash'
+
+export type TestCaseFields = {
+ name?: string
+ id?: string | number
+ ID?: string
+ desc?: string
+ sutEdge?: boolean
+ sutHisp?: boolean
+ sutRole?: string
+ criteria?: string
+ status?: string
+ inputs?: InputFields[]
+ 'Test Focus'?: string
+ 'Data Flow in Direct'?: string
+ 'Metadata Included'?: string
+ 'Direct Address Block'?: string
+ 'SUT: Sender/ Receiver'?: string
+ 'Test Tool: Sender / Receiver'?: string
+ 'Purpose/Description'?: string
+ 'Conformance Test Details'?: string
+ 'Expected Test Results'?: string
+ 'Required / Conditional per Direct Edge Protocol Guide'?: string
+ 'Direct Edge Protocol Guide 1.1 RTM Reference'?: number
+ 'Test Data IDs'?: string | null
+}
+
+export type InputFields = {
+ name?: string
+ hoverlabel?: string
+ key?: string
+ type?: string
+}
+
+export interface TestCardProps {
+ test: TestCaseFields
+}
+interface StepTextProps {
+ inputs: InputFields[]
+ role?: string
+}
+const handleClick = (link: string) => {
+ navigator.clipboard
+ .writeText(link)
+ .then(() => {
+ alert('Link copied to clipboard: ' + link)
+ })
+ .catch((err) => {
+ console.error('Failed to copy link: ', err)
+ alert('Failed to copy link. Please try again.')
+ })
+}
+const flexColumnStyle = {
+ display: 'flex',
+ flexDirection: 'column',
+ width: '100%',
+ pt: 2,
+}
+
+const senderText = 'Hit Run to generate your endpoint.'
+const receiverText = 'Hit Run to send a XDR message.'
+const endpoint = 'http://ett.healthit.gov:11080/xdstools/sim/'
+const endpointTLS = 'https://ett.healthit.gov:11084/xdstools/sim/'
+
+const StepText = ({ inputs, role }: StepTextProps) => {
+ return (
+ <>
+
+ Step 1: Provide your{' '}
+ {inputs.map((input, i) => {
+ return (
+
+ {input.name}
+ {inputs !== undefined ? (i === inputs.length - 1 ? '. ' : ', ') : '. '}
+
+ )
+ })}
+ {role === 'sender' && senderText}
+ {role === 'receiver' && receiverText}
+
+
+ )
+}
+const TestCard = ({ test }: TestCardProps) => {
+ return (
+
+
+
+
+
+ {test.desc}
+
+ {_.isEqual(test.sutRole, 'receiver') && _.has(test, 'inputs') && test.inputs !== undefined && (
+
+ )}
+ {_.isEqual(test.sutRole, 'sender') && _.has(test, 'inputs') && test.inputs !== undefined && (
+
+ )}
+ {_.has(test, 'inputs') &&
+ test.inputs !== undefined &&
+ test.inputs.map((input) => {
+ return (
+
+
+
+ {input.hoverlabel}
+
+
+ )
+ })}
+
+
+
+ {/* Note: This might change with functionality to generate the endpoint*/}
+
+ {_.includes(
+ ['10', '11', '12', '32mu2', '33mu2', '34mu2', '35mu2', '36mu2', '37mu2', '38mu2', '43mu2', '44mu2'],
+ test.ID
+ ) && (
+
+
+ }
+ onClick={() => handleClick(endpoint + 'edge-ttp__' + test.ID + '/rep/xdrpr')}
+ >
+ Endpoint
+
+ }
+ onClick={() => handleClick(endpointTLS + 'edge-ttp__' + test.ID + '/rep/xdrpr')}
+ >
+ Endpoint TLS
+
+
+
+ )}
+
+
+
+
+
+
+
+
+ )
+}
+export default TestCard
diff --git a/src/components/direct/hisp/data/SMTPTestCases.tsx b/src/components/direct/hisp/data/SMTPTestCases.tsx
new file mode 100644
index 00000000..b8b74310
--- /dev/null
+++ b/src/components/direct/hisp/data/SMTPTestCases.tsx
@@ -0,0 +1,1178 @@
+const testCases = {
+ testingMode: false,
+ tests: [
+ {
+ name: 'SMTP Test 8, 14, 18 (Send)',
+ id: 1,
+ protocol: 'smtp',
+ desc: 'Verifies the ability of the sending system to send an email to ETT using the SMTP protocol with STARTTLS and PLAIN SASL Authentication (if enabled). The SUT will send an email to wellformed1@ttpedge.sitenv.org. Hitting Run will cause ETT to search for an email sent to wellformed1@ttpedge.sitenv.org from the email address entered in Profile window. Note that the C-CDA Document Type selected will not affect the test result.',
+ longDesc:
+ 'Run this series collectively from one action: Test 8 validates basic commands (HELO, MAIL FROM, RCPT TO) and STARTTLS. Test 14 validates SASL AUTH. For Test 18 the SUT needs to connect to the ETT SMTP server using the credentials vendoraccount@ttpds.sitenv.org / vendortesting123 and send an email to wellformed1@ttpedge.sitenv.org. \n The validator is designed to use an XML attachment, sending a PDF is permitted for transport; however, it will not validate.',
+ sutRole: 'sender',
+ sutHisp: false,
+ criteria: "['b1-8']",
+ sutEdge: true,
+ ccdaFileRequired: true,
+ fields: [
+ {
+ label: 'C-CDA Document Type',
+ name: 'ccdaReferenceFilename',
+ datatype: 'CCDAWidget',
+ value: 'ccdaReferenceFilename',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP Test 8, 14 (Send)',
+ id: 2,
+ protocol: 'smtp',
+ desc: "Verifies the ability of the sending system to send an email to ETT using the SMTP protocol with STARTTLS. The SUT will send an email to edge-receiver@ttpds.sitenv.org. Hitting 'Run' will cause ETT to search for an email sent to edge-receiver@ttpds.sitenv.org from the email address entered in Profile window. Note that the C-CDA Document Type selected will not affect the test result.",
+ longDesc:
+ 'Run this series collectively from one action: Test 8 validates basic commands (HELO, MAIL FROM, RCPT TO) and STARTTLS, and Test 14, sending an email to edge-receiver@ttpds.sitenv.org. \n The validator is designed to use an XML attachment, sending a PDF is permitted for transport; however, it will not validate.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-13']",
+ sutEdge: false,
+ ccdaFileRequired: true,
+ fields: [
+ {
+ label: 'C-CDA Document Type',
+ name: 'ccdaReferenceFilename',
+ datatype: 'CCDAWidget',
+ value: 'ccdaReferenceFilename',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP Test 9, 16, 20 (Receive)',
+ id: 16,
+ protocol: 'smtp',
+ desc: "Verifies the ability of the receiving system to accept a STARTTLS connection with PLAIN SASL authentication(if enabled). Hitting 'Run' will cause ETT to send an email. Verify the receipt of email with subject 'STARTTLS & PLAIN SASL AUTHENTICATION'.",
+ longDesc:
+ "Run this series collectively from one action: Test 9 and 16 verifies the ability of the receiving system to accept a STARTTLS connection with PLAIN SASL authentication. Hitting 'Run' will cause ETT to send an email (Test 20). Verify the receipt of email with subject 'STARTTLS & PLAIN SASL AUTHENTICATION'. If TLS Required is unchecked in the profile--STARTTLS validation will be ignored. ",
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['h2-8','b1-4','b1-7','su1-4','su1-7','sc2-8']",
+ sutEdge: true,
+ ccdaFileRequired: true,
+ fields: [
+ {
+ label: 'C-CDA Document Type',
+ name: 'ccdaReferenceFilename',
+ datatype: 'CCDAWidgetReceiver',
+ value: 'ccdaReferenceFilename',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP Test 10 (Reject Invalid DATA)',
+ id: 10,
+ protocol: 'smtp',
+ desc: "Negative Test: Verifies the ability of the receiving system to REJECT invalid data as part of DATA command. Hitting 'Run' will cause ETT to begin an SMTP transaction to the Vendor SMTP Hostname/IP entered into Profile window. A correct REJECTION will cause the SMTP session to end before the email is delivered.",
+ longDesc:
+ "The objective of this test sequence is to determine if an Edge System (e.g., SUT), acting as the receiver, rejects data sent from a HISP (e.g., ETT), acting as the sender, as a component of a successfully established and active session. Successful establishment of an end-point to end-point connection between the SUT and ETT is a necessary function for SMTP Test Case 10 execution.\n The details for conformance testing flow are as follows: The ETT will initiate a connected session with the SUT and attempt to send an invalid data via the DATA command (e.g., bad line feeds).\n This is required test and maintains compliance with the secure health data transport messaging formats, processing requirements, and communication standards for Direct Edge message exchanges. See Section 1.2.1 and 1.2.2 of the 'Implementation Guide for Direct Edge Protocols' document. \n The test correlates to Test ID 10 of the SMTP Test Cases (tab) within the 'DirectEdgeProtocols' spreadsheet.",
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['h2-8']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 11 (Reject Bad Commands)',
+ id: 11,
+ protocol: 'smtp',
+ desc: "Negative Tests: Verifies the ability of the receiving system to REJECT bad SMTP commands. ETT will send invalid SMTP commands following exception paths identified in Section 4.1.1 and 4.1.4 of RFC 2821. Hitting 'Run' will cause ETT to begin the invalid transactions to the Vendor SMTP Hostname/IP entered into Profile window.",
+ longDesc:
+ "The objective of this test sequence is to determine if an Edge System (e.g., SUT), acting as the receiver, rejects as invalid the commands sent from a HISP (e.g., ETT), acting as the sender./n The details for conformance testing flow are as follows: The ETT attempts to initiate a session with the SUT by sending an invalid SMTP command following identified exception paths. The test attempts to determine if the SUT rejects the command sent by the Edge Testing Tool as invalid and responds using the appropriate mechanisms. This is conducted in accordance with RFC 2811, Section 4.1.1 and 4.1.4 (e.g., closing the session abruptly).\n This is required test and maintains compliance with the secure health data transport messaging formats, processing requirements, and communication standards for Direct Edge message exchanges. See Section 1.2.1 and 1.2.2 of the 'Implementation Guide for Direct Edge Protocols' document. \nThe test correlates to Test ID 11 of the SMTP Test Cases (tab) within the 'DirectEdgeProtocols' spreadsheet. ",
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['h2-8']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 13 (Command Timeout)',
+ id: 13,
+ protocol: 'smtp',
+ desc: "Verifies the ability of the receiving system to correctly timeout for various SMTP commands. The tool will keep the transaction open until a timeout is noted. As there are no required time limits in RFC 2821 section 4.5.3.2, this test is configurable. Hitting 'Run' will begin the ETT's timer based on the value in seconds entered below. The default entry, 0, allows a maximum time-out (no limit). Enter a value greater than your systems time-out period to perform this test.",
+ longDesc:
+ "The objective of this test sequence is to determine if an Edge System (e.g., SUT), acting as the receiver, can successfully establish an active session with a HISP (e.g., ETT), acting as the sender, and conform to the specific timeout requirements within the RFC and SMTP command.\n The details for conformance testing flow are as follows: The ETT will initiate a connected session with the SUT. The SUT will attempt to keep a transaction open with the ETT for beyond the specified time constraints found within RFC 2821, Section 4.5.3.2. \nThis is required test and maintains compliance with the secure health data transport messaging formats, processing requirements, and communication standards for Direct Edge message exchanges. See Section 1.2.1 and 1.2.2 of the 'Implementation Guide for Direct Edge Protocols' document. ",
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['h2-8']",
+ sutEdge: true,
+ fields: [
+ {
+ label: 'Command timeout in seconds',
+ name: 'sutCommandTimeoutInSeconds',
+ datatype: 'String',
+ value: 'sutCommandTimeoutInSeconds',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP MT Test 17 - Generate Unique Message-ID (Processed MDN suite)',
+ id: 117,
+ protocol: 'mu2',
+ desc: "Verifies the ability of the sending system to send messages with unique message-IDs. The sending system will send multiple messages (at least 3) to wellformed14@ttpds.sitenv.org. Hitting 'Run' will cause ETT to check the message IDs for uniqueness (use this case if you opt for 'Message tracking using Processed MDN').",
+ longDesc: 'The credentials for authentication is vendoraccount@ttpds.sitenv.org / vendortesting123 ',
+ sutRole: 'sender',
+ sutHisp: false,
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP MT Test 45 - Generate Unique Message-ID (IG for Delivery Notification Suite)',
+ id: 145,
+ protocol: 'mu2',
+ desc: "Verifies the ability of the sending system to send messages with unique message-IDs and a properly formed Disposition Notification Options Header. The sending system will send multiple messages (at least 3) to wellformed14@ttpds.sitenv.org. Hitting 'Run' will cause ETT to check the message IDs for uniqueness (2014 Edition Note: use this case if you opt for 'Message tracking using Implementation Guide for Delivery Notification').",
+ longDesc: 'The credentials for authentication is vendoraccount@ttpds.sitenv.org / vendortesting123 ',
+ sutRole: 'sender',
+ sutHisp: false,
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP MT Test 46 (Generate Disposition Notification Options Header)',
+ id: 146,
+ protocol: 'mu2',
+ desc: "Verifies the ability of the sending system to send messages with a correct Disposition Notification Options Header. The sending system will send a message to wellformed14@ttpds.sitenv.org with the required header. Hitting 'Run' will cause ETT to check for this header.",
+ longDesc: 'The credentials for authentication is vendoraccount@ttpds.sitenv.org / vendortesting123 ',
+ sutRole: 'sender',
+ sutHisp: false,
+ criteria: "['b1-2','su1-2']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP MT Test 47 - Accept failure message for invalid recipient (IG for Delivery Notification Suite - IMAP/POP Receiver)',
+ id: 147,
+ protocol: 'mu2',
+ desc: "Verifies the ability of the system to accept failure messages for some of the recipients. The system shall send a single email to multiple recipients: valid one (dispatchedonly-plain@ttpedge.sitenv.org) and an invalid address (noaddressfailure9-plain@dnsops.ttpedge.sitenv.org ). The MDNs are delivered to the 'Mail From' address. The failure MDN for invalid recipient noaddressfailure9-plain@dnsops.ttpedge.sitenv.org needs to be verified.",
+ longDesc:
+ 'The credentials for authentication is vendoraccount@ttpds.sitenv.org / vendortesting123. This is a test case for systems that receive using SMTP. ',
+ sutRole: 'sender',
+ sutHisp: false,
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 22 (Reject invalid username/password)',
+ id: 22,
+ protocol: 'smtp',
+ desc: "Verifies the ability of the receiving to reject a PLAIN SASL connection. Hitting 'Run' will cause ETT to use an invalid username/password to authenticate to the system entered into Vendor SMTP Hostname/IP in the profile window.",
+ longDesc:
+ "The objective of this test sequence is to determine if an Edge System (e.g., SUT), acting as the receiver, will reject and fail to authenticate an invalid PLAIN SASL request sent from a HISP (e.g., ETT), acting as the sender.\nThe details for conformance testing flow are as follows: The ETT will send an invalid PLAIN SASL username/password authentication scheme to the SUT. The SUT will receive the invalid PLAIN SASL username/password, reject the credentials, and fail to established authentication to the ETT. The PLAIN SASL connection mechanisms will conform to the specified requirements within RFC 4616, Section 2.\n This is conditional test and maintains compliance with the secure health data transport messaging formats, processing requirements, and communication standards for Direct Edge message exchanges. See Section 1.2.4 of the 'Implementation Guide for Direct Edge Protocols' document.\n The test correlates to Test ID 22 of the SMTP Test Cases (tab) within the 'DirectEdgeProtocols' spreadsheet. ",
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['h2-8']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 25(a) (Receive Text and CCDA)',
+ id: 91,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive text and CCDA attachments',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4','su1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 25(b) (Receive PDF and CCDA)',
+ id: 92,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive PDF and CCDA attachments',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4','su1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 25(c) (Receive Text and XDM)',
+ id: 93,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive text and XDM attachments',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4','su1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 25(d) (Receive CCDA and Text)',
+ id: 94,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive CCDA and text attachments',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4','su1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 25(e) (Receive CCDA and Pdf)',
+ id: 95,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive CCDA and PDF attachments',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4','su1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 25(f) (Receive XDM and Text)',
+ id: 96,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive XDM and text attachments',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4','su1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 26(a) (Receive bad CCDA)',
+ id: 97,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive a CCDA document that includes a broken reference to a style-sheet.',
+ longDesc:
+ ' Verifies the ability of SUT to receive a CCDA document that includes a broken reference to a style-sheet. \n Expected outcome: SUT will accept the C-CDA despite the problems.',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 26(b) (Receive bad CCDA)',
+ id: 98,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive a CCDA document with good reference to an invalid style-sheet',
+ longDesc:
+ ' Verifies the ability of SUT to receive a CCDA document with good reference to an invalid style-sheet. \n Expected outcome: SUT will accept the C-CDA despite the problems.',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP Test 27 (Receive XDM with bad XHTML)',
+ id: 99,
+ protocol: 'smtp',
+ desc: ' Verifies the ability of SUT to receive an XDM package containing a bad XHTML file',
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4']",
+ sutEdge: true,
+ },
+ {
+ name: "SMTP Test 28 (Receive XDM with MIME type 'application/octet-stream')",
+ id: 100,
+ protocol: 'smtp',
+ desc: " Verifies the ability of SUT to receive an XDM package with MIME-type 'application/octet-stream' at the SMTP layer",
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4','su1-4']",
+ sutEdge: true,
+ },
+ {
+ name: "SMTP Test 29 (Receive XDM with MIME type 'application/xml')",
+ id: 90,
+ protocol: 'smtp',
+ desc: " Verifies the ability of Vendor to receive an XDM package with MIME-type 'application/xml' at the XDM layer (in METADATA.XML)",
+ sutRole: 'receiver',
+ sutHisp: true,
+ criteria: "['b1-4','su1-4']",
+ sutEdge: true,
+ },
+ {
+ name: 'SMTP MT Test 1 (Message to Non-Existent Address)',
+ id: 101,
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an invalid address. Hitting 'Run' will cause ETT to send a message with a final destination that is not valid. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ longDesc: 'The email is sent to badaddresst@ttpds2.sitenv.org',
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 2 (Receiving HISP Not Trusted)',
+ id: 102,
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an untrusted address). Hitting 'Run' will cause ETT to send a message to an untrusted final address. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ longDesc: 'The email is sent to direct2.sitenv.org',
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: "SMTP MT Test 3 (Recipient's Certificate Not Published)",
+ id: 103,
+ longDesc: 'The email is sent to failure15@ttpds.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not have a published certificate. Hitting 'Run' will cause ETT to send a message with a final destination that does not have a published certificate. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 4 (No Processed MDN)',
+ id: 104,
+ longDesc: 'The email is sent to nomdn8@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a processed MDN. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a processed MDN. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 5 (Message to Bad Address)',
+ id: 105,
+ longDesc: 'The email is sent to badaddresst@ttpds2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an invalid address. Hitting 'Run' will cause ETT to send a message with a final destination that is not valid. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 6 (Receiving HISP Not Trusted)',
+ id: 106,
+ longDesc: 'The email is sent to direct2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an untrusted address. Hitting 'Run' will cause ETT to send a message with a final destination that is not a trusted HISP. The expectation is that if the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: "SMTP/IMAP MT Test 7 (Recipient's Certificate Not Published)",
+ id: 107,
+ longDesc: 'The email is sent to failure15@ttpds.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not have a published certificate. Hitting 'Run' will cause ETT to send a message with a final destination that does not have a published certificate. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 8 (No Processed MDN)',
+ id: 108,
+ longDesc: 'The email is sent to nomdn8@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a processed MDN. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a processed MDN. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 9 (Message to Bad Address)',
+ id: 109,
+ longDesc: 'The email is sent to badaddresst@ttpds2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an invalid address. Hitting 'Run' will cause ETT to send a message with a final destination that is not valid. The expectation is that if the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 10 (Receiving HISP Not Trusted)',
+ id: 110,
+ longDesc: 'The email is sent to direct2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an untrusted address. Hitting 'Run' will cause ETT to send a message with a final destination that is not a trusted HISP. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: "SMTP/POP MT Test 11 (Recipient's Certificate Not Published)",
+ id: 111,
+ longDesc: 'The email is sent to failure15@ttpds.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not have a published certificate. Hitting 'Run' will cause ETT to send a message with a final destination that does not have a published certificate. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 12 (No Processed MDN)',
+ id: 112,
+ longDesc: 'The email is sent to nomdn8@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a processed MDN. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a processed MDN. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-4','sc2-4']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 21(a) (Message with Good Header)',
+ id: 521,
+ longDesc: 'The email is sent to processeddispatched6@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to properly process the Disposition-Notifications-Options Header. Hitting 'Run' will cause ETT to send a message with an appropriate Disposition-Notifications-Options Header. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the positive delivery status notification message.The expectation is that the Vendor will handle the header appropriately and provide a processed MDN.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 21(b) (Message with Good Header)',
+ id: 121,
+ longDesc: 'The email is sent to processeddispatched6@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to properly process the Disposition-Notifications-Options Header. Hitting 'Run' will cause ETT to send a message with an appropriate Disposition-Notifications-Options Header. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag).The expectation is that the Vendor will handle the header appropriately and provide a processed MDN.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 21(c) (Message with Good Header)',
+ id: 151,
+ longDesc: 'The email is sent to processeddispatched6@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to properly process the Disposition-Notifications-Options Header. Hitting 'Run' will cause ETT to send a message with an appropriate Disposition-Notifications-Options Header. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that the Vendor will handle the header appropriately and provide a processed MDN.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 23(a) (Message to Bad Address)',
+ id: 523,
+ longDesc: 'The email is sent to badaddresst@ttpds2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an invalid address. Hitting 'Run' will cause ETT to send a message with a final destination that is not valid. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 23(b) (Message to Bad Address)',
+ id: 123,
+ longDesc: 'The email is sent to badaddresst@ttpds2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an invalid address. Hitting 'Run' will cause ETT to send a message with a final destination that is not valid. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 23(c) (Message to Bad Address)',
+ id: 623,
+ longDesc: 'The email is sent to badaddresst@ttpds2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an invalid address. Hitting 'Run' will cause ETT to send a message with a final destination that is not valid. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 24(a) (Receiving HISP Not Trusted)',
+ id: 524,
+ longDesc: 'The email is sent to badaddresst@ttpds2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an untrusted HISP. Hitting 'Run' will cause ETT to send a message with a final destination that is not a trusted HISP. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 24(b) (Receiving HISP Not Trusted)',
+ id: 124,
+ longDesc: 'The email is sent to direct2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an untrusted HISP(direct2.sitenv.org). Hitting 'Run' will cause ETT to send a message with a final destination that is not a trusted HISP. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 24(c) (Receiving HISP Not Trusted)',
+ id: 624,
+ longDesc: 'The email is sent to direct2.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to an untrusted HISP. Hitting 'Run' will cause ETT to send a message with a final destination that is not a trusted HISP. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: "SMTP MT Test 25(a) (Recipient's Certificate Not Published)",
+ id: 525,
+ longDesc: 'The email is sent to failure15@ttpds.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not have a published certificate. Hitting 'Run' will cause ETT to send a message with a final destination that does not have a published certificate. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: "SMTP/IMAP MT Test 25(b) (Recipient's Certificate Not Published)",
+ id: 125,
+ longDesc: 'The email is sent to failure15@ttpds.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not have a published certificate. Hitting 'Run' will cause ETT to send a message with a final destination that does not have a published certificate. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: "SMTP/POP MT Test 25(c) (Recipient's Certificate Not Published)",
+ id: 625,
+ longDesc: 'The email is sent to failure15@ttpds.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not have a published certificate. Hitting 'Run' will cause ETT to send a message with a final destination that does not have a published certificate. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 26(a) (No Processed MDN)',
+ id: 526,
+ longDesc: 'The email is sent to nomdn8@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a processed MDN due to an exceeded wait time. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a processed MDN. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 26(b) (No Processed MDN)',
+ id: 126,
+ longDesc: 'The email is sent to nomdn8@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a processed MDN due to an exceeded wait time. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a processed MDN. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 26(c) (No Processed MDN)',
+ id: 626,
+ longDesc: 'The email is sent to nomdn8@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a processed MDN due to an exceeded wait time. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a processed MDN. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 27(a) (No Dispatched MDN)',
+ id: 527,
+ longDesc: 'The email is sent to processedonly5@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a dispatched MDN. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a dispatched MDN. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 27(b) (No Dispatched MDN)',
+ id: 127,
+ longDesc: 'The email is sent to processedonly5@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a dispatched MDN. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a dispatched MDN. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 27(c) (No Dispatched MDN)',
+ id: 157,
+ longDesc: 'The email is sent to processedonly5@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a dispatched MDN. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a dispatched MDN. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 28(a) (Delayed Dispatched MDN)',
+ id: 528,
+ longDesc:
+ 'This test is setup to allow a (N) + 5 minute timeout for the failure MDN, where N is the value entered to run the test. To run this test, enter the value (N) that the SUT will wait before generating a failure MDN. If the SUT sends an MDN prior to its default timeout (N), the test will fail. Sending a message between (N) and (N) + 5 min, no failure or success will be recorded. The test is setup to allow a buffer for the delivery of Dispatched MDN from the ETT as a Receiving HISP. Steps to run the test: 1) Enter the SUT timeout value (N) into the test input parameter box, 2) Select Run, 3) wait for (N) + 5 min, then select Check MDN. A PASS will result only if a FAILURE Notification and NO Success Notification is sent (Which means if no Failure Notification found or both found will generate failure). If the ETT receives a Dispatch MDN, the test will result in a Failure.',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a dispatched MDN after the expected wait time is exceeded. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a dispatched MDN. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the negative delivery status notification message. The expectation is that an appropriate delivery failure message indicating a timeout will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ fields: [
+ {
+ label: 'Timeout in minutes',
+ name: 'sutCommandTimeoutInSeconds',
+ datatype: 'String',
+ placeHolder: 'Timeout In Minutes',
+ value: 'Timeout In Minutes',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP/IMAP MT Test 28(b) (Delayed Dispatched MDN)',
+ id: 128,
+ longDesc:
+ 'This test is setup to allow a (N) + 5 minute timeout for the failure MDN, where N is the value entered to run the test. To run this test, enter the value (N) that the SUT will wait before generating a failure MDN. If the SUT sends an MDN prior to its default timeout (N), the test will fail. Sending a message between (N) and (N) + 5 min, no failure or success will be recorded. The test is setup to allow a buffer for the delivery of Dispatched MDN from the ETT as a Receiving HISP. Steps to run the test: 1) Enter the SUT timeout value (N) into the test input parameter box, 2) Select Run, 3) wait for (N) + 5 min, then select Check MDN. A PASS will result only if a FAILURE Notification and NO Success Notification is sent (Which means if no Failure Notification found or both found will generate failure). If the ETT receives a Dispatch MDN, the test will result in a Failure.',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a dispatched MDN after the expected wait time is exceeded. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a dispatched MDN. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message indicating a timeout will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ fields: [
+ {
+ label: 'Timeout in minutes',
+ name: 'sutCommandTimeoutInSeconds',
+ placeHolder: 'Timeout In Minutes',
+ datatype: 'String',
+ value: 'Timeout In Minutes',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP/POP MT Test 28(c) (Delayed Dispatched MDN)',
+ id: 158,
+ longDesc:
+ 'This test is setup to allow a (N) + 5 minute timeout for the failure MDN, where N is the value entered to run the test. To run this test, enter the value (N) that the SUT will wait before generating a failure MDN. If the SUT sends an MDN prior to its default timeout (N), the test will fail. Sending a message between (N) and (N) + 5 min, no failure or success will be recorded. The test is setup to allow a buffer for the delivery of Dispatched MDN from the ETT as a Receiving HISP. Steps to run the test: 1) Enter the SUT timeout value (N) into the test input parameter box, 2) Select Run, 3) wait for (N) + 5 min, then select Check MDN. A PASS will result only if a FAILURE Notification and NO Success Notification is sent (Which means if no Failure Notification found or both found will generate failure). If the ETT receives a Dispatch MDN, the test will result in a Failure.',
+ desc: "Verify the ability of the system to provide a delivery failure message when a message is sent to a destination that does not return a dispatched MDN after the expected wait time is exceeded. Hitting 'Run' will cause ETT to send a message with a final destination that will not provide a dispatched MDN. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate delivery failure message indicating a timeout will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9']",
+ sutEdge: false,
+ fields: [
+ {
+ label: 'Timeout in minutes',
+ name: 'sutCommandTimeoutInSeconds',
+ placeHolder: 'Timeout In Minutes',
+ datatype: 'String',
+ value: 'Timeout In Minutes',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP MT Test 29(a) (Positive Notification)',
+ id: 529,
+ longDesc: 'The email is sent to processeddispatched6@ttpedge.sitenv.org',
+ desc: 'Verify the ability of the system to provide a final positive delivery notification when a message is sent to a destination that has responding appropriately. Due to SMTP-SMTP configuration limitations, the proctor is to visually inspect for the receipt of the positive delivery status notification message. The expectation is that an appropriate final positive delivery notification will be returned.',
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9','sc2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/IMAP MT Test 29(b) (Positive Notification)',
+ id: 129,
+ longDesc: 'The email is sent to processeddispatched6@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a final positive delivery notification when a message is sent to a destination that has responding appropriately. Hitting 'Run' will cause ETT to send a message with a final destination that will respond appropriately. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate final positive delivery notification will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9','sc2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP/POP MT Test 29(c) (Positive Notification)',
+ id: 159,
+ longDesc: 'The email is sent to processeddispatched6@ttpedge.sitenv.org',
+ desc: "Verify the ability of the system to provide a final positive delivery notification when a message is sent to a destination that has responding appropriately. Hitting 'Run' will cause ETT to send a message with a final destination that will respond appropriately. If the message was sent successfully 'Check MDN' will appear. Clicking that will check for the incoming MDN (may have to click multiple times due to lag). The expectation is that an appropriate final positive delivery notification will be returned.",
+ protocol: 'mu2',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-9','sc2-9']",
+ sutEdge: false,
+ },
+ {
+ name: 'SMTP MT Test 39 (Message with Good Header)',
+ id: 139,
+ desc: "Verify the ability of the system to properly process the Disposition-Notifications-Options Header. Hitting 'Run' will cause ETT to send a message with a well-formed Disposition-Notifications-Options Header. If the message is sent successfully 'Check MDN' will appear. Clicking that will check for the expected Processed and Dispatched MDN (Note that you may have to click multiple times due to lag.) The expected result is a Processed and Dispatched MDN. The selection of a file is optional, if the system requires clinical information with the message.",
+ protocol: 'mu2',
+ longDesc:
+ 'If you are acting as a Receiving HISP and need to load your trust anchor and certificates to properly to receive MDNs, please request this service on the mailing list. ',
+ sutRole: 'receiver',
+ criteria: "['h1-1','h2-10','sa1-1','sc2-10']",
+ sutHisp: true,
+ sutEdge: false,
+ fields: [
+ {
+ label: 'C-CDA Document Type',
+ name: 'ccdaReferenceFilename',
+ datatype: 'CCDAWidgetReceiver',
+ value: 'ccdaReferenceFilename',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP MT Test 40 (Message with Bad Header)',
+ id: 140,
+ desc: "Verify the ability of the system to process an invalid Disposition-Notifications-Options Header. Hitting 'Run' will cause ETT to send a message with an incorrect Disposition-Notifications-Options Header. If the message is sent successfully 'Check MDN' will appear. Clicking that will check for the expected Processed MDN (Note that you may have to click multiple times due to lag.) The expected result is that the Vendor will be able to process the invalid Disposition-Notifications-Options Header and respond with a Processed MDN. Optionally, the test will accommodate systems that also respond with a Dispatched MDN--however the Dispatched MDN must NOT contain the X-DIRECT-FINAL-DESTINATION-DELIVERY header to pass. The selection of a file is optional, if the system requires clinical information with the message.",
+ protocol: 'mu2',
+ longDesc:
+ 'If you are acting as a Receiving HISP and need to load your trust anchor and certificates to properly to receive MDNs, please request this service on the mailing list. ',
+ sutRole: 'receiver',
+ criteria: "['h1-1','h2-10','sa1-1','sc2-10']",
+ sutHisp: true,
+ sutEdge: false,
+ fields: [
+ {
+ label: 'C-CDA Document Type',
+ name: 'ccdaReferenceFilename',
+ datatype: 'CCDAWidgetReceiver',
+ value: 'ccdaReferenceFilename',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'SMTP MT Test 41 (Unable to deliver)',
+ id: 142,
+ desc: 'Verifies that when the system successfully validates security and trust, but cannot deliver the message to its final destination, the system generates an MDN failed or a failure DSN. ETT (as Sending HISP) sends a well-formed message to a destination address. The system decrypts and trust validates the message, returning a Processed MDN. The system is unable to deliver the message (mail box full, unavailable, mailbox does not exist) and returns either an MDN failed or a failure Delivery Status Notification. The selection of a file is optional, if the system requires clinical information with the message.',
+ protocol: 'mu2',
+ longDesc:
+ 'If you are acting as a Receiving HISP and need to load your trust anchor and certificates to properly to receive MDNs, please request this service on the mailing list. ',
+ sutRole: 'receiver',
+ criteria: "['h1-1','sa1-1','sc2-10']",
+ sutHisp: true,
+ sutEdge: false,
+ fields: [
+ {
+ label: 'C-CDA Document Type',
+ name: 'ccdaReferenceFilename',
+ datatype: 'CCDAWidgetReceiver',
+ value: 'ccdaReferenceFilename',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'IMAP Test 1, 2, 3',
+ id: 201,
+ protocol: 'imap',
+ desc: 'Verifies IMAP4 CAPABILITY, NOOP and LOGOUT commands are implemented.',
+ longDesc: 'The test tool connects to the vendor on the standard IMAP port 143.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-5']",
+ sutEdge: false,
+ },
+ {
+ name: 'POP Test 1, 2',
+ id: 301,
+ protocol: 'pop',
+ desc: 'Verifies POP3 CAPA, NOOP and QUIT commands are implemented.',
+ longDesc: 'The test tool connects to the vendor on the standard POP3 port 110.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-6']",
+ sutEdge: false,
+ },
+ {
+ name: 'POP Test 5, 11, 15',
+ id: 303,
+ protocol: 'pop',
+ desc: 'Verifies POP3 STAT, STLS, RETR, LIST, RSET and QUIT commands are implemented',
+ longDesc:
+ 'The vendor has to provide the profile information (hostname, username, password) and an account with preloaded email. ',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-6']",
+ sutEdge: false,
+ },
+ {
+ name: 'POP Test 9',
+ id: 309,
+ protocol: 'pop',
+ desc: 'Verifies the ability of the Vendor HISP(POP Server) to reject a command when a command with bad syntax is sent.',
+ longDesc: 'The test tool connects to the vendor on the standard POP3 port 110.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-6']",
+ sutEdge: false,
+ },
+ {
+ name: 'POP Test 10',
+ id: 310,
+ protocol: 'pop',
+ desc: 'Verifies the ability of the Vendor HISP(POP Server) to reject a command in bad state.',
+ longDesc: 'The test tool connects to the vendor on the standard POP3 port 110.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-6']",
+ sutEdge: false,
+ },
+ {
+ name: 'POP Test 17',
+ id: 317,
+ protocol: 'pop',
+ desc: 'Verifies the ability of the Vendor HISP(POP Server) to reject authentication when bad username/password is used.',
+ longDesc: 'The test tool connects to the vendor on the standard POP3 port 110.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-6']",
+ sutEdge: false,
+ },
+ {
+ name: 'IMAP Test 8, 11, 15',
+ id: 205,
+ protocol: 'imap',
+ desc: 'Verifies the ability of the Vendor HISP to implement imap commands.(AUTHENTICATE, STARTTLS, LOGIN, SELECT, FETCH)',
+ longDesc:
+ 'The vendor has to provide the profile information (hostname, username, password) and an account with preloaded email. ',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-5']",
+ sutEdge: false,
+ },
+ {
+ name: 'IMAP Test 9',
+ id: 209,
+ protocol: 'imap',
+ desc: 'Verifies the ability of the Vendor HISP to reject a command when a command with bad syntax is sent.',
+ longDesc: 'The test tool connects to the vendor on the standard IMAP port 143.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-5']",
+ sutEdge: false,
+ },
+ {
+ name: 'IMAP Test 10',
+ id: 210,
+ protocol: 'imap',
+ desc: 'Verifies the ability of the Vendor HISP to reject commands with right syntax based on the specific state of the connection.',
+ longDesc: 'The test tool connects to the vendor on the standard IMAP port 143.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-5']",
+ sutEdge: false,
+ },
+ {
+ name: 'IMAP Test 17',
+ id: 217,
+ protocol: 'imap',
+ desc: 'Verifies the ability of the Vendor HISP to reject incorrect username/password.',
+ longDesc: 'The test tool connects to the vendor on the standard IMAP port 143.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-5']",
+ sutEdge: false,
+ },
+ {
+ name: 'IMAP Test 19, 20, 24',
+ id: 219,
+ protocol: 'imap',
+ desc: "Verifies the ability of the Edge system to initiate a IMAP session with STARTTLS and PLAIN SASL AUTHENTICATION(if enabled). The Vendor should retrieve an email from 'imaptesting@ttpds.sitenv.org'.",
+ longDesc:
+ 'Run this series collectively from one action: Test 19 invokes the STARTTLS validation and Test 20 validates the SASL authentication. Test 24 invokes the retrieve validation. It is necessary to configure an email account on the SUT in order to retrieve messages using these credentials: imaptesting@ttpds.sitenv.org / smtptesting123.',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5']",
+ sutEdge: true,
+ },
+ {
+ name: 'IMAP Test 21',
+ id: 221,
+ protocol: 'imap',
+ desc: "Verifies the ability of the Vendor to use either the uppercase, lowercase or mixed case mailbox names and access data. The Vendor should fetch emails from imaptesting@ttpds.sitenv.org within the folders 'FOLDER' and 'folder2'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is imaptesting@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5']",
+ sutEdge: true,
+ },
+ {
+ name: 'IMAP Test 25',
+ id: 225,
+ protocol: 'imap',
+ desc: 'Verifies the ability of the Vendor to receive status and size updates from the IMAP4 server. An email will be sent to the SUT and the SUT will show size and status updates (e.g change in the number of emails in inbox) when new email is received',
+ longDesc:
+ 'The proctor needs to send an email to the Vendor and should verify that the Vendor system is able to show size and status updates (e.g change in the number of emails in inbox) when new email is received ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5']",
+ sutEdge: true,
+ },
+ {
+ name: 'IMAP Test 27',
+ id: 227,
+ protocol: 'imap',
+ desc: "Verifies the ability of the Vendor to accept XDM packages sent using different MIME Types. The SUT should fetch emails from 'xdmmimetypes@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is xdmmimetypes@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5']",
+ sutEdge: true,
+ },
+ {
+ name: 'IMAP Test 28',
+ id: 228,
+ protocol: 'imap',
+ desc: "Verifies the ability of the Vendor to accept multiple attachments (in varying order). The Vendor should fetch an email from 'multipleattachments@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is multipleattachments@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5']",
+ sutEdge: true,
+ },
+ {
+ name: 'IMAP Test 29(a)',
+ id: 2291,
+ protocol: 'imap',
+ desc: "Test for the ability of the Vendor to accept C-CDA even when the CCDA document includes a broken reference to a style-sheet. The Vendor should fetch an email from 'brokenrefstylesheet@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is brokenrefstylesheet@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5']",
+ sutEdge: true,
+ },
+ {
+ name: 'IMAP Test 29(b)',
+ id: 2292,
+ protocol: 'imap',
+ desc: "Test for the ability of the Vendor to accept C-CDA even when the CCDA document includes a good reference to an invalid style-sheet.. The Vendor should fetch an email from 'invalidstylesheet@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is invalidstylesheet@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5']",
+ sutEdge: true,
+ },
+ {
+ name: 'IMAP Test 30',
+ id: 230,
+ protocol: 'imap',
+ desc: "Verifies the ability of the Vendor to accept XDM package even in the case where the required XHTML is bad. The Vendor should fetch an email from 'xdmbadxhtml@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is xdmbadxhtml@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5']",
+ sutEdge: true,
+ },
+ {
+ name: 'IMAP Test 31 (Receive)',
+ id: 231,
+ protocol: 'imap',
+ desc: 'Verifies the ability of the SUT to accept different attachment types.',
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is b1-ambulatory@ttpds.sitenv.org, b1-inpatient@ttpds.sitenv.org, b2-ambulatory@ttpds.sitenv.org, b2-inpatient@ttpds.sitenv.org, b5-ambulatory@ttpds.sitenv.org, b5-inpatient@ttpds.sitenv.org, b9-ambulatory@ttpds.sitenv.org, b9-inpatient@ttpds.sitenv.org, negativetestingccds@ttpds.sitenv.org, negativetestingcareplan@ttpds.sitenv.org. The password is smtptesting123 for all accounts. ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-5','su1-5']",
+ sutEdge: true,
+ fields: [
+ {
+ label: 'Attachment type',
+ name: 'attachmentType',
+ datatype: 'DropdownString',
+ allowedValues: [
+ '170.315(b)(1)-Transitions of Care-Ambulatory Setting',
+ '170.315(b)(1)-Transitions of Care-Inpatient Setting',
+ '170.315(b)(2)-Clinical Information Reconciliation and Incorporation-Ambulatory Setting',
+ '170.315(b)(2)-Clinical Information Reconciliation and Incorporation-Inpatient Setting',
+ '170.315(b)(5)-Common Clinical Data Set Summary Record-Ambulatory Setting',
+ '170.315(b)(5)-Common Clinical Data Set Summary Record-Inpatient Setting',
+ '170.315(b)(9)-Care Plan-Ambulatory Setting',
+ '170.315(b)(9)-Care Plan-Inpatient Setting',
+ 'NegativeTesting_CCDS',
+ 'NegativeTesting_CarePlan',
+ ],
+ value: 'attachmentType',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'IMAP 32 (Receive + Validate)',
+ id: 232,
+ protocol: 'imap',
+ desc: 'Verifies the ability of the SUT to host attachments and make it available for fetching through IMAP. The CCDA is validated using the MDHT validator.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-5']",
+ sutEdge: false,
+ ccdaFileRequired: true,
+ fields: [
+ {
+ label: 'C-CDA Document Type',
+ name: 'ccdaReferenceFilename',
+ datatype: 'CCDAWidget',
+ value: 'ccdaReferenceFilename',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'POP Test 19, 20, 24',
+ id: 319,
+ protocol: 'pop',
+ desc: "Verifies the ability of the SUT to support various POP3 commands. The proctor need to send commands to the ETT and retrieve an email from 'poptesting@ttpds.sitenv.org'.",
+ longDesc:
+ 'Run this series collectively from one action: Test 19 validates the TLS session. Test 20 validates the SASL authentication. Test 24 invokes the retrieve validation. It is necessary to configure an email account on the SUT in order to retrieve messages using these credentials: poptesting@ttpds.sitenv.org / smtptesting123.',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-6']",
+ sutEdge: true,
+ },
+ {
+ name: 'POP Test 27',
+ id: 327,
+ protocol: 'pop',
+ desc: "Verifies the ability of the SUT to accept XDM packages sent using different MIME Types. The Vendor should fetch emails from 'xdmmimetypes@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is xdmmimetypes@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-6']",
+ sutEdge: true,
+ },
+ {
+ name: 'POP Test 28',
+ id: 328,
+ protocol: 'pop',
+ desc: "Verifies the ability of the SUT to accept multiple attachments (in varying order). The Vendor should fetch emails from 'multipleattachments@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is multipleattachments@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-6']",
+ sutEdge: true,
+ },
+ {
+ name: 'POP Test 29(a)',
+ id: 3291,
+ protocol: 'pop',
+ desc: "Test for the ability of the Vendor to accept C-CDA even when the CCDA document includes a broken reference to a style-sheet. The Vendor should fetch an email from 'brokenrefstylesheet@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is brokenrefstylesheet@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-6']",
+ sutEdge: true,
+ },
+ {
+ name: 'POP Test 29(b)',
+ id: 3292,
+ protocol: 'pop',
+ desc: "Test for the ability of the Vendor to accept C-CDA even when the CCDA document includes a good reference to an invalid style-sheet.. The Vendor should fetch an email from 'invalidstylesheet@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is invalidstylesheet@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-6']",
+ sutEdge: true,
+ },
+ {
+ name: 'POP Test 30',
+ id: 330,
+ protocol: 'pop',
+ desc: "Verifies the ability of the SUT to accept XDM package even in the case where the required XHTML is bad. The Vendor should fetch emails from 'xdmbadxhtml@ttpds.sitenv.org'.",
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is xdmbadxhtml@ttpds.sitenv.org / smtptesting123 ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-6']",
+ sutEdge: true,
+ },
+ {
+ name: 'POP Test 31 (Receive)',
+ id: 331,
+ protocol: 'pop',
+ desc: 'Verifies the ability of the SUT to accept different attachment types.',
+ longDesc:
+ 'The user is to establish or configure an email account on the SUT in order to retrieve messages using the credentials. The credentials for authentication is b1-ambulatory@ttpds.sitenv.org, b1-inpatient@ttpds.sitenv.org, b2-ambulatory@ttpds.sitenv.org, b2-inpatient@ttpds.sitenv.org, b5-ambulatory@ttpds.sitenv.org, b5-inpatient@ttpds.sitenv.org, b9-ambulatory@ttpds.sitenv.org, b9-inpatient@ttpds.sitenv.org, negativetestingccds@ttpds.sitenv.org, negativetestingcareplan@ttpds.sitenv.org. The password is smtptesting123 for all accounts. ',
+ sutRole: 'receiver',
+ sutHisp: false,
+ criteria: "['b1-6','su1-6']",
+ sutEdge: true,
+ fields: [
+ {
+ label: 'Attachment type',
+ name: 'attachmentType',
+ datatype: 'DropdownString',
+ allowedValues: [
+ '170.315(b)(1)-Transitions of Care-Ambulatory Setting',
+ '170.315(b)(1)-Transitions of Care-Inpatient Setting',
+ '170.315(b)(2)-Clinical Information Reconciliation and Incorporation-Ambulatory Setting',
+ '170.315(b)(2)-Clinical Information Reconciliation and Incorporation-Inpatient Setting',
+ '170.315(b)(5)-Common Clinical Data Set Summary Record-Ambulatory Setting',
+ '170.315(b)(5)-Common Clinical Data Set Summary Record-Inpatient Setting',
+ '170.315(b)(9)-Care Plan-Ambulatory Setting',
+ '170.315(b)(9)-Care Plan-Inpatient Setting',
+ 'NegativeTesting_CCDS',
+ 'NegativeTesting_CarePlan',
+ ],
+ value: 'attachmentType',
+ readOnly: false,
+ display: true,
+ },
+ ],
+ },
+ {
+ name: 'POP 32 (Receive + Validate)',
+ id: 332,
+ protocol: 'pop',
+ desc: 'Verifies the ability of the SUT to host attachments and make it available for fetching through POP. The CCDA is validated using the MDHT validator.',
+ sutRole: 'sender',
+ sutHisp: true,
+ criteria: "['h2-6']",
+ sutEdge: false,
+ fields: [
+ {
+ label: 'C-CDA Document Type',
+ name: 'ccdaReferenceFilename',
+ datatype: 'CCDAWidget',
+ value: 'ccdaReferenceFilename',
+ readOnly: false,
+ ccdaFileRequired: true,
+ display: true,
+ },
+ ],
+ },
+ ],
+}
+
+export default testCases
diff --git a/src/components/direct/hisp/data/XDRTestCases.tsx b/src/components/direct/hisp/data/XDRTestCases.tsx
new file mode 100644
index 00000000..92a501bf
--- /dev/null
+++ b/src/components/direct/hisp/data/XDRTestCases.tsx
@@ -0,0 +1,1622 @@
+const testCases = [
+ {
+ name: 'XDR Test 1',
+ id: 1,
+ ID: '1',
+ desc: 'Verifies the ability of the sending system to initiate a SOAP-based communication with an XDR-based payload. This test uses Limited XDR metadata.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ criteria: "['b1-1']",
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'C-CDA Document Type',
+ key: 'payload',
+ type: 'CCDAWidgetXdr',
+ },
+ ],
+ 'Test Focus': 'XDR Send ',
+ 'Data Flow in Direct': 'Edge Sends an XDR message to HISP along with Direct Address block',
+ 'Metadata Included': 'Limited Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Receiver (Test Tool)',
+ 'Purpose/Description':
+ 'Verify that the Edge system can create an XDR message per the specification. Per the Test Procedure, the user is to select a payload for transmission that meets the test scenario with regard to 170_b1_ToC_Amb or 170.315_b1_ToC_Inp. The user should select the C-CDA document type that matches the architecture for the document they are sending.',
+ 'Conformance Test Details':
+ 'XDR Message Checklist + XDS Metadata Checklist for Limited Metadata Document Source + Direct Address Block',
+ 'Expected Test Results': 'Edge System produces the right message and conforms to the specification.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 2',
+ id: 2,
+ ID: '2',
+ desc: 'Verifies the ability of the sending system to initiate a SOAP-based communication with an XDR-based payload. This test uses Full XDR metadata.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ criteria: "['b1-1']",
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'C-CDA Document Type',
+ key: 'payload',
+ type: 'CCDAWidgetXdr',
+ },
+ ],
+ 'Test Focus': 'XDR Send',
+ 'Data Flow in Direct': 'Edge Sends an XDR message to HISP along with Full Metadata',
+ 'Metadata Included': 'Full Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Receiver (Test Tool)',
+ 'Purpose/Description': 'Verify that the Edge system can create an XDR message per the specification',
+ 'Conformance Test Details':
+ 'XDR Message Checklist + XDS Metadata Checklist for Full Metadata Document Source + Direct XDR Checklist',
+ 'Expected Test Results': 'Edge System produces the right message and conforms to the specification.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'O',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 3',
+ id: '3add',
+ ID: '3add',
+ desc: 'Verify the ability of the receiving system to correctly receive a properly formatted XDR message with Limited metadata.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'receiver',
+ criteria: "['b1-3','su1-3']",
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'C-CDA Document Type',
+ key: 'payload',
+ type: 'CCDAWidgetReceiverXdr',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'Edge receives an XDR message from the HISP',
+ 'Metadata Included': 'Limited Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "Verify that an Edge system can receive a properly formatted XDR message. The SUT will receive the XDR message with a 'direct:from' and 'direct:to' address of testcase3add@ttpedge.sitenv.org. This was designed to require the SUT's endpoint as the only input parameter.",
+ 'Conformance Test Details': '',
+ 'Expected Test Results':
+ 'Edge system is capable of receiving and processing a valid message, test procedure may include other details for verification. Test Tool is satisfied with a good response.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 4a',
+ id: '4a',
+ ID: '4a',
+ desc: 'Verify the ability of the receiving system to appropriately respond to a malformed message. This test is for an invalid SOAP header.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'receiver',
+ criteria: "['b1-3']",
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'Edge receives an incorrect XDR message from the HISP',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Receiver (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "Verify that the Edge system throws an error when an incorrect message is received. The SUT will receive the XDR message with a 'direct:from' and 'direct:to' address of testcase4a@ttpedge.sitenv.org. This was designed to require the SUT's endpoint as the only input parameter.",
+ 'Conformance Test Details': 'Create incorrect messages which include Bad SOAP Envelope Details',
+ 'Expected Test Results': 'Edge system is rejecting the various bad messages sent from the test tool.',
+ 'Required / Conditional per Direct Edge Protocol Guide ': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference ': 1.1,
+ 'Test Data IDs ': null,
+ },
+ {
+ name: 'XDR Test 4b',
+ id: '4b',
+ ID: '4b',
+ desc: 'Verify the ability of the receiving system to appropriately respond to a malformed message. This test is for an invalid SOAP body.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'receiver',
+ criteria: "['b1-3']",
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'Edge receives an incorrect XDR message from the HISP',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Receiver (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "Verify that the Edge system throws an error when an incorrect message is received. The SUT will receive the XDR message with a 'direct:from' and 'direct:to' address of testcase4b@ttpedge.sitenv.org. This was designed to require the SUT's endpoint as the only input parameter.",
+ 'Conformance Test Details': 'Create incorrect messages which include Bad SOAP Body Details',
+ 'Expected Test Results': 'Edge system is rejecting the various bad messages sent from the test tool.',
+ 'Required / Conditional per Direct Edge Protocol Guide ': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference ': 1.1,
+ 'Test Data IDs ': null,
+ },
+ {
+ name: 'XDR Test 5',
+ id: 5,
+ ID: '5',
+ desc: 'Verify the ability of the receiving system to correctly receive a properly formatted XDR message with Full (XDS) metadata.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'receiver',
+ criteria: "['b1-3','su1-3']",
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'Edge receives an XDR message from the HISP',
+ 'Metadata Included': 'Full Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "Verify that an Edge system can receive a properly formatted XDR message. The SUT will receive the XDR message with a 'direct:from' and 'direct:to' address of testcase5@ttpedge.sitenv.org. This was designed to require the SUT's endpoint as the only input parameter.",
+ 'Conformance Test Details': '',
+ 'Expected Test Results':
+ 'Edge system is capable of receiving and processing a valid message with Full Metadata, test procedure may include other details for verification. Test Tool is satisfied with a good response.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 6',
+ id: 6,
+ ID: '6',
+ desc: 'Verifies the ability of the sending system to complete a mutual TLS handshake before data is sent across.\nNote that an unsuccessful TLS attempt may result in the Pending Refresh button being displayed instead of a Fail. A disconnection happening at the server level would cause the communication not to be forwarded to the application level.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ criteria: "['b1-1']",
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'Authentication',
+ 'Data Flow in Direct': 'Edge uses Mutual TLS to authenticate to the HISP',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Server (Test Tool)',
+ 'Purpose/Description':
+ 'Verify that Mutual TLS session is established between the Sender and the Receiver before transimitting data. The Tester (i.e., Vendor) assures that the appropriate XDR Certificates have been downloaded from the ETT and imported into the SUT trust store before executing the test.',
+ 'Conformance Test Details': 'Require Mutual TLS in the configuration',
+ 'Expected Test Results':
+ 'Edge Sysem is capable of establishing the Mutual TLS connection prior to transmitting the data.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 7',
+ id: 7,
+ ID: '7',
+ desc: 'Verifies the ability of the sending system to reject a mutual TLS connection where the certificate provided by the ETT is invalid. If you experience Pending Refresh or a Fail that you think is incorrect, please run this test again but wait 15 seconds after the connection has been dropped for the ETT to fully test the socket connection.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ criteria: "['b1-1']",
+ inputs: [
+ {
+ name: 'IP Address',
+ key: 'ip_address',
+ hoverlabel: 'IP Address (eg: 202.255.24.62)',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'Authentication',
+ 'Data Flow in Direct': 'Edge uses Mutual TLS to authenticate to the HISP exception case',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Server (Test Tool)',
+ 'Purpose/Description': 'Verify that Edge disconnects when the Server provided certificate is invalid.',
+ 'Conformance Test Details': 'Incorrect Mutual TLS configuration should not proceed.',
+ 'Expected Test Results': 'Edge Sysem rejects the connection from the Server due to bad certificate.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': 'Column J is not necessary.',
+ },
+ {
+ name: 'XDR Test 8',
+ id: 8,
+ ID: '8',
+ desc: 'Verifies the ability of the receiving system to complete a mutual TLS handshake before data is sent across. Certificates for this test can be downloaded from the link at the top of this page. This is a socket-level test, the full endpoint is not necessary. Enter only IP Address and port below.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'receiver',
+ criteria: "['b1-3']",
+ inputs: [
+ {
+ name: 'IP Address',
+ key: 'ip_address',
+ hoverlabel: 'IP Address (eg: 202.255.24.62)',
+ type: 'string',
+ },
+ {
+ name: 'Port',
+ key: 'port',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'Authentication',
+ 'Data Flow in Direct': 'HISP authenticates to the Edge using Mutual TLS',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Receiver (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Client (Test Tool)',
+ 'Purpose/Description': 'Test Tool authenticates with the Edge using Mutual TLS correctly',
+ 'Conformance Test Details': 'Require Mutual TLS in the configuration in the Edge system',
+ 'Expected Test Results': 'Edge System is capable of accepting and validating a Mutual TLS connection.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 9',
+ id: 9,
+ ID: '9',
+ desc: 'Verifies the ability of the receiving system to reject a mutual TLS connection where the certificate provided by the ETT is invalid. Certificates for this test can be downloaded from the link at the top of this page. As this is a socket-level test, the full endpoint is not necessary and only IP Address and port are to be entered below. The SUT MUST attempt an HTTPS connection.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'receiver',
+ criteria: "['b1-3']",
+ inputs: [
+ {
+ name: 'IP Address',
+ key: 'ip_address',
+ hoverlabel: 'IP Address (eg: 202.255.24.62)',
+ type: 'string',
+ },
+ {
+ name: 'Port',
+ key: 'port',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'Authentication',
+ 'Data Flow in Direct': 'HISP authenticates to the Edge using Mutual TLS exception case',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Receiver (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': 'Client (Test Tool)',
+ 'Purpose/Description': 'Test Tool authenticates with the Edge using bad certificates',
+ 'Conformance Test Details': 'Incorrect Mutual TLS configuration should not proceed.',
+ 'Expected Test Results':
+ 'Edge System rejects the connection due to the bad certificate published by the Test Tool.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 10',
+ id: 10,
+ ID: '10',
+ desc: 'Test Tool sends a Direct Message to the SUT. The SUT must translate this to an XDR message and send it back to the Edge.\nVerify that the HISP system can create an XDR message per the specification and forward to Edge. The return endpoint is provided below. The validation report will be sent to the email address registered with the Direct address enter during setup.',
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'sender',
+ criteria: "['h2-1','h2-3','sc2-1','sc2-3']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Direct To Address',
+ hoverlabel:
+ "Direct To Address: SUT's receiving email endpoint for Direct/XDR translation, ETT to SUT workflow.",
+ key: 'direct_to',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Send ',
+ 'Data Flow in Direct': 'HISP Sends an XDR message to Edge',
+ 'Metadata Included': 'Limited Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Sender (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Receiver (Test Tool)',
+ 'Purpose/Description':
+ "Test Tool sends a Direct Message, which is translated to an XDR message and sent to the Edge.\nVerify that the HISP system can create an XDR message per the specification and forward to Edge. The validation report will be sent to the email address registered with the Direct address enter during setup. Direct To Address: SUT's receiving email endpoint for Direct/XDR translation, ETT to SUT workflow. The SUT will receive a message from testcase10@ttpedge.sitenv.org",
+ 'Conformance Test Details':
+ 'XDR Message Checklist + XDS Metadata Checklist for Limited Metadata Document Source + Direct XDR Checklist',
+ 'Expected Test Results':
+ 'HISP generates an XDR message with Limited Metadata from a Direct Message and forwards to Edge.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 11',
+ id: 11,
+ ID: '11',
+ desc: 'Test Tool sends a Direct Message + XDM to the SUT. The SUT must translate this to an XDR message with Limited Metadata and send it back to the Edge.\nVerify that the HISP system can create an XDR message per the specification and forward to Edge. The return endpoint is provided below. The validation report will be sent to the email address registered with the Direct address enter during setup.',
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'sender',
+ criteria: "['h2-1','h2-3','sc2-1','sc2-3']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Direct To Address',
+ hoverlabel:
+ "Direct To Address: SUT's receiving email endpoint for Direct/XDR translation, ETT to SUT workflow.",
+ key: 'direct_to',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Send',
+ 'Data Flow in Direct': 'HISP Sends an XDR message to Edge with Limited Metadata',
+ 'Metadata Included': 'Limited Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Sender (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Receiver (Test Tool)',
+ 'Purpose/Description':
+ "Test Tool sends a Direct Message + XDM, which is translated to an XDR message with Limited Metadata and sent to the Edge.\nVerify that the HISP system can create an XDR message per the specification and forward to Edge. The validation report will be sent to the email address registered with the Direct address enter during setup. Direct To Address: SUT's receiving email endpoint for Direct/XDR translation, ETT to SUT workflow. The SUT will receive a message from testcase11@ttpedge.sitenv.org.",
+ 'Conformance Test Details':
+ 'XDR Message Checklist + XDS Metadata Checklist for Limited Metadata Document Source + Direct XDR Checklist',
+ 'Expected Test Results':
+ 'HISP generates an XDR message with Limited Metadata from a Direct Message and forwards to Edge.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 12',
+ id: 12,
+ ID: '12',
+ desc: 'Test Tool sends a Direct Message + XDM to the SUT. The SUT must translate this to an XDR message with Full Metadata and send it back to the Edge.\nVerify that the HISP system can create an XDR message per the specification and forward to Edge. The return endpoint is provided below.The validation report will be sent to the email address registered with the Direct address enter during setup.',
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'sender',
+ criteria: "['h2-1','h2-3','sc2-1','sc2-3']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Direct To Address',
+ hoverlabel:
+ "Direct To Address: SUT's receiving email endpoint for Direct/XDR translation, ETT to SUT workflow.",
+ key: 'direct_to',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Send',
+ 'Data Flow in Direct': 'HISP Sends an XDR message to Edge along with Full Metadata',
+ 'Metadata Included': 'Full Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Sender (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Receiver (Test Tool)',
+ 'Purpose/Description':
+ "Test Tool sends a Direct Message + XDM, which is translated to an XDR message with Full Metadata and sent to the Edge.\nVerify that the HISP system can create an XDR message per the specification and forward to Edge. The validation report will be sent to the email address registered with the Direct address enter during setup. Direct To Address: SUT's receiving email endpoint for Direct/XDR translation, ETT to SUT workflow. The SUT will receive a message from testcase12@ttpedge.sitenv.org.",
+ 'Conformance Test Details':
+ 'XDR Message Checklist + XDS Metadata Checklist for Full Metadata Document Source + Direct XDR Checklist',
+ 'Expected Test Results':
+ 'HISP generates an XDR message with Full Metadata from a Direct Message and forwards to Edge.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'O',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 13',
+ id: 13,
+ ID: '13',
+ desc: 'Before this test is run, the vendor must register a Direct Address / Contact address pairing using the Direct portion of the ETT tool.\nTest Tool sends an XDR Message with Limited metadata to the SUT (HISP). The SUT must then translate the message into Direct and send it back to the ETT which is acting as the Destination HISP. The Direct Address it passes the message along to must match the Direct Address that has been pre-registered. A validation report will be sent to the Contact address.\nVerify that an HISP system can receive a properly formatted XDR message and translate to Direct Message.',
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'receiver',
+ criteria: "['h2-2','h2-7','sc2-2','sc2-7']",
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'Limited Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "Test Tool sends an XDR Message to the HSIP which then translates the message to Direct and sends to the other HISP.\nVerify that an HISP system can receive a properly formatted XDR message and translate to Direct Message.\nNote: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed.",
+ 'Conformance Test Details':
+ 'XDR Message Checklist + XDS Metadata Checklist for Limited Metadata Document Source + Direct XDR Checklist',
+ 'Expected Test Results': 'HISP receives an XDR message and converts to a Direct + XDM Message.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 13',
+ id: '32mu2',
+ ID: '32mu2',
+ desc: "Verify the ability of the SUT to appropriately respond to a delivery to a non-existent address. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Message Tracking Using Processed MDN test suite.",
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'receiver',
+ criteria: "['h2-3','sc2-3']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The ETT (as Edge) sends a message to the Health IT Module using a bad address, such that the Health IT Module is unable to deliver the message. The Health IT Module delivers a failure message to the ETT (as Edge) using the XDR profile due to a bad address. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details':
+ "Conforms to section 1.5.2.1.1 of the Direct Edge Protocol Implementation Guide 1.1, including an appropriately filled 'direct:disposition' element in the XML payload",
+ 'Expected Test Results': 'The message disposition must indicate a failure.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 14',
+ id: 14,
+ ID: '14',
+ desc: 'Before this test is run, the vendor must register a Direct Address / Contact address pairing using the Direct portion of the ETT tool.\nTest Tool sends an XDR Message with Full (XDS) metadata to the SUT (HISP). The SUT must then translate the message into Direct and send it back to the ETT which is acting as the Destination HISP. The Direct Address it passes the message along to must match the Direct Address that has been pre-registered. A validation report will be sent to the Contact address.\nVerify that an HISP system can receive a properly formatted XDR message and translate to Direct Message.',
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'receiver',
+ criteria: "['h2-2','h2-7','sc2-2','sc2-7']",
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge along with Full Metadata',
+ 'Metadata Included': 'Full Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "Test Tool sends an XDR Message with Full Metadata to the HSIP which then translates the message to Direct and sends to the other HISP.\nVerify that an HISP system can receive a properly formatted XDR message and translate to Direct Message.\nNote: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed.",
+ 'Conformance Test Details':
+ 'XDR Message Checklist + XDS Metadata Checklist for Full Metadata Document Source + Direct XDR Checklist',
+ 'Expected Test Results': 'HISP receives an XDR message and converts to a Direct Message.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'O',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 14',
+ id: '33mu2',
+ ID: '33mu2',
+ desc: "Verify the ability of the SUT to appropriately respond to a delivery to an untrusted HISP. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Message Tracking Using Processed MDN test suite.",
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'receiver',
+ criteria: "['h2-3','sc2-3']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct':
+ 'The ETT (as Edge) sends a message to the Health IT Module using a valid address, but the ETT (as Destination HISP) is not trusted.',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The ETT (as Edge) sends a message to the Health IT Module using a valid address, but the ETT (as Destination HISP) is not trusted. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details': 'Conforms to section 1.5.2.1.1 of the Direct Edge Protocol Implementation Guide 1.1',
+ 'Expected Test Results':
+ 'The Health IT Module delivers a failure message to the ETT (as Edge) using the XDR profile due to an untrusted HISP (ETT as Destination HISP)',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 15a',
+ id: '15a',
+ ID: '15a',
+ desc: 'Verify the ability of the receiving system to appropriately respond to a malformed message. This test is for an invalid SOAP header.',
+ sutEdge: false,
+ criteria: "['h2-7']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an incorrect XDR message from the Edge',
+ 'Metadata Included': 'Limited Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description': 'Verify that the HISP system throws an error when an incorrect message is received.',
+ 'Conformance Test Details': 'Create an incorrect message with invalid SOAP envelope details',
+ 'Expected Test Results': 'HISP should validate the messages per the specification and reject the bad messages',
+ 'Required / Conditional per Direct Edge Protocol Guide ': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference ': 1.1,
+ 'Test Data IDs ': null,
+ },
+ {
+ name: 'XDR Test 15b',
+ id: '15b',
+ ID: '15b',
+ desc: 'Verify the ability of the receiving system to appropriately respond to a malformed message. This test is for an invalid SOAP body.',
+ sutEdge: false,
+ criteria: "['h2-7']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an incorrect XDR message from the Edge',
+ 'Metadata Included': 'Limited Metadata',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description': 'Verify that the HISP system throws an error when an incorrect message is received.',
+ 'Conformance Test Details': 'Create an incorrect message with invalid SOAP body details',
+ 'Expected Test Results': 'HISP should validate the messages per the specification and reject the bad messages',
+ 'Required / Conditional per Direct Edge Protocol Guide ': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference ': 1.1,
+ 'Test Data IDs ': null,
+ },
+ {
+ name: 'XDR MT Test 15',
+ id: '34mu2',
+ ID: '34mu2',
+ desc: "Verify the ability of the SUT to appropriately respond to a delivery to a HISP which does not have a published certificate. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Message Tracking Using Processed MDN test suite.",
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'receiver',
+ criteria: "['h2-3','sc2-3']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "Verify the ability of the SUT to appropriately respond to a delivery to a HISP which does not have a published certificate. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details':
+ 'Create and send a valid XDR message, with a valid destination with an unpublished certificate',
+ 'Expected Test Results':
+ 'The SUT will respond with a message that conforms to section 1.5.2.1.1 of the Direct Edge Protocol Implementation Guide 1.1',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 16',
+ id: 16,
+ ID: '16',
+ desc: 'Verify that Mutual TLS session is established between the Sender and the Receiver before transimitting data.',
+ sutEdge: false,
+ criteria: "['h2-3','sc2-3']",
+ sutHisp: true,
+ sutRole: 'sender',
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'Authentication',
+ 'Data Flow in Direct': 'HISP uses Mutual TLS to authenticate to the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Client (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Server (Test Tool)',
+ 'Purpose/Description':
+ 'Verify that Mutual TLS session is established between the Sender and the Receiver before transimitting data.',
+ 'Conformance Test Details': 'Require Mutual TLS in the configuration',
+ 'Expected Test Results': 'HISP should initiate a connection to the Edge using Mutual TLS correctly.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 16',
+ id: '35mu2',
+ ID: '35mu2',
+ desc: "Verify the ability of the SUT to appropriately respond in the event of a lack of a Processed MDN. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Message Tracking Using Processed MDN test suite.",
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'receiver',
+ criteria: "['h2-3']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "Verify the ability of the SUT to appropriately respond to a delivery to a HISP due to an extended wait period using an XDR profile. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details':
+ 'Create and send a valid XDR message, with a valid destination with an extended wait period, time-out scenario, failure message.',
+ 'Expected Test Results':
+ 'The SUT will respond with a message that conforms to section 1.5.2.1.1 of the Direct Edge Protocol Implementation Guide 1.1',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 17',
+ id: 17,
+ ID: '17',
+ desc: 'Verify that HISP disconnects when the Server provided certificate is invalid. Only the IP address of the SUT shall be entered below. As this is a socket based test, the full endpoint is not required. Only the IP Address and port are needed and provided.',
+ sutEdge: false,
+ sutHisp: true,
+ sutRole: 'sender',
+ criteria: "['h2-3']",
+ inputs: [
+ {
+ name: 'IP Address',
+ hoverlabel: 'IP Address (eg: 202.255.24.62)',
+ key: 'ip_address',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'Authentication',
+ 'Data Flow in Direct': 'HISP uses Mutual TLS to authenticate to the Edge exception case',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Client (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Server (Test Tool)',
+ 'Purpose/Description': 'Verify that HISP disconnects when the Server provided certificate is invalid.',
+ 'Conformance Test Details': 'Incorrect Mutual TLS configuration should not proceed.',
+ 'Expected Test Results': 'HISP should disconnect when the certificate from the edge is bad.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 18',
+ id: 18,
+ ID: '18',
+ desc: 'Test Tool authenticates with the HISP using Mutual TLS correctly. Certificates for this testing tool can be downloaded from the top of this page. This is a socket-level test, the full endpoint is not required. Enter only the IP Address and port below.',
+ sutEdge: false,
+ criteria: "['h2-7']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ inputs: [
+ {
+ name: 'IP Address',
+ hoverlabel: 'IP Address (eg: 202.255.24.62)',
+ key: 'ip_address',
+ type: 'string',
+ },
+ {
+ name: 'Port',
+ key: 'port',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'Authentication',
+ 'Data Flow in Direct': 'Edge authenticates to the HISP using Mutual TLS',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Server (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Client (Test Tool)',
+ 'Purpose/Description': 'Test Tool authenticates with the HISP using Mutual TLS correctly',
+ 'Conformance Test Details': 'Require Mutual TLS in the configuration in the Edge system',
+ 'Expected Test Results': 'HISP should accept a connection from the Edge for Mutual TLS correctly.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR Test 19',
+ id: 19,
+ ID: '19',
+ desc: 'Test Tool authenticates with the HISP using bad certificates. The SUT is expected to disconnect before any meaningful data is sent. Certificates for this testing tool can be downloaded from the top of this page. This is a socket-level test, the full endpoint is not required. Enter only the IP Address and port below.',
+ sutEdge: false,
+ sutHisp: true,
+ criteria: "['h2-7']",
+ sutRole: 'receiver',
+ inputs: [
+ {
+ name: 'IP Address',
+ hoverlabel: 'IP Address (eg: 202.255.24.62)',
+ key: 'ip_address',
+ type: 'string',
+ },
+ {
+ name: 'Port',
+ key: 'port',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'Authentication',
+ 'Data Flow in Direct': 'Edge authenticates to the HISP using Mutual TLS exception case',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Server (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Client (Test Tool)',
+ 'Purpose/Description': 'Test Tool authenticates with the HISP using bad certificates',
+ 'Conformance Test Details': 'Incorrect Mutual TLS configuration should not proceed.',
+ 'Expected Test Results': 'HISP should disconnect when the certificate from the edge is bad.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 19',
+ id: '19mu2',
+ ID: '19mu2',
+ desc: "Verifies the ability of the sending system to send messages with unique message-IDs. Hit 'RUN' and then the sending system will send three messages with unique identifiers to the endpoint provided. When all three messages have been completely sent, press the 'Pending Refresh' button.",
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': '',
+ 'Data Flow in Direct': '',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': '',
+ 'Purpose/Description':
+ 'Test to validate that the Edge system is able to create messages with unique message id for XDR profile.',
+ 'Conformance Test Details': '',
+ 'Expected Test Results': 'Edge system creates each message with a unique message id with no duplicates.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 20a',
+ id: '20amu2',
+ ID: '20mu2',
+ desc: 'Verifies the ability of the sending system to initiate an XDR transaction to ETT and to receive a positive (success) delivery status notification. The test lab will inspect the SUT logs and system to verify that the response was handled appropriately.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ criteria: "['b1-1','su1-1']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ expectedMDN: true,
+ 'Test Focus': '',
+ 'Data Flow in Direct': '',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': '',
+ 'Purpose/Description':
+ 'The SUT should send the test message to Testcase20a@ttpedge.sitenv.org. This is a preconfigured address and designed to accommodate the variety of Systems that are testing with minimal user input. The users will see a message from the ETT to allow easy recognition.',
+ 'Conformance Test Details': '',
+ 'Expected Test Results': 'Edge system receives and processes a positive (success) delivery status notification.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 20b',
+ id: '20bmu2',
+ ID: '20bmu2',
+ desc: 'Verifies the ability of the sending system to initiate an XDR transaction to ETT and to receive negative (failure) delivery status notification. The test lab will inspect the SUT logs and system to verify that the response was handled appropriately.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ criteria: "['b1-1','su1-1']",
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ expectedMDN: true,
+ 'Test Focus': '',
+ 'Data Flow in Direct': '',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': '',
+ 'Purpose/Description':
+ 'The SUT should send the test message to Testcase20b@ttpedge.sitenv.org. This is a preconfigured address and designed to accommodate the variety of Systems that are testing with minimal user input. The users will see a message from the ETT to allow easy recognition.',
+ 'Conformance Test Details': '',
+ 'Expected Test Results': 'Edge system receives and processes a negative (failure) delivery status notification..',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 30',
+ id: '30mu2',
+ ID: '30mu2',
+ desc: 'Verify the ability of the receiving system to appropriately handle a VALID delivery notifications request, including X-DIRECT-FINAL-DESTINATION-DELIVERY data. ETT will create the Direct address block Header following section 4.1 of the XDR and XDM for Direct Messaging v1.0 and include the X-DIRECT-FINAL-DESTINATION-DELIVERY data following section 1.3 of Implementation Guide for Delivery Notification in Direct v1.0 and send it to the SUT.',
+ sutEdge: false,
+ criteria: "['h2-11','sc2-11']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct To Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_to',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process a valid message from the ETT. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details':
+ 'HISP should appropriately handle a VALID delivery notification request, including X-DIRECT-FINAL-DESTINATION-DELIVERY data.',
+ 'Expected Test Results':
+ 'The Health IT Module is able to successfully process a message from the ETT (as Sending Edge)',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 31',
+ id: '31mu2',
+ ID: '31mu2',
+ desc: 'Verify the ability of the receiving system to appropriately handle an INVALID delivery notifications request, including X-DIRECT-FINAL-DESTINATION-DELIVERY data. ETT will create the Direct address block Header following section 4.1 of the XDR and XDM for Direct Messaging v1.0 and include INVALID X-DIRECT-FINAL-DESTINATION-DELIVERY data following section 1.3 of Implementation Guide for Delivery Notification in Direct v1.0 and send it to the SUT.',
+ sutEdge: false,
+ criteria: "['h2-11','sc2-11']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process an invalid message from the ETT, message contains a valid address block and invalid destination.\nNote: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed.",
+ 'Conformance Test Details':
+ 'HISP should appropriately handle an INVALID delivery notification request, including X-DIRECT-FINAL-DESTINATION-DELIVERY data.',
+ 'Expected Test Results':
+ 'The Health IT Module is able to process the header handle an invalid delivery notification request',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 32',
+ id: '32mu2',
+ ID: '32mu2',
+ desc: "Verify the ability of the SUT to appropriately respond to a delivery to a non-existent address. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite.",
+ sutEdge: false,
+ criteria: "['h2-11']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) that includes an invalid (non-existent) address. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details':
+ 'HISP should appropriately handle an INVALID address and send the negative delivery notification back to the EDGE.',
+ 'Expected Test Results':
+ 'The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 33',
+ id: '33mu2',
+ ID: '33mu2',
+ desc: "Verify the ability of the SUT to appropriately respond to a delivery to an untrusted HISP. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite.",
+ sutEdge: false,
+ criteria: "['h2-11']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) is not trusted. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details':
+ 'XDR Message Checklist + XDS Metadata Checklist for Limited Metadata Document Source + Direct XDR Checklist',
+ 'Expected Test Results':
+ 'The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 34',
+ id: '34mu2',
+ ID: '34mu2',
+ desc: "Verify the ability of the SUT to appropriately respond to a delivery to a HISP which does not have a published certificate. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite.",
+ sutEdge: false,
+ criteria: "['h2-11']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) does not have published certificates, and security and trust processing fails. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details': 'The HISP sends a negative delivery status notification message back to the EDGE.',
+ 'Expected Test Results':
+ 'The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 35',
+ id: '35mu2',
+ ID: '35mu2',
+ desc: "Verify the ability of the SUT to appropriately respond in the event of a lack of a Processed MDN. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite.",
+ sutEdge: false,
+ criteria: "['h2-11']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) does not respond with a Processed MDN. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details': 'The HISP sends a negative delivery status notification message back to the EDGE.',
+ 'Expected Test Results':
+ 'The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 36',
+ id: '36mu2',
+ ID: '36mu2',
+ desc: "Verify the ability of the SUT to appropriately respond in the event of a lack of a Dispatched MDN. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite.",
+ sutEdge: false,
+ criteria: "['h2-11']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) responds with a Processed MDN, but no Dispatched MDN. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details': 'The HISP sends a negative delivery status notification message back to the EDGE.',
+ 'Expected Test Results':
+ 'The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 37',
+ id: '37mu2',
+ ID: '37mu2',
+ desc: "Verify the ability of the SUT to appropriately respond in the event of a message timeout failure. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite.",
+ sutEdge: false,
+ criteria: "['h2-11']",
+ sutHisp: true,
+ status: 'configure',
+ sutRole: 'receiver',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) responds with a Processed MDN, but the Dispatched MDN is received after the expected wait time has exceeded. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details': 'The HISP sends a negative delivery status notification message back to the EDGE.',
+ 'Expected Test Results':
+ 'The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 38',
+ id: '38mu2',
+ ID: '38mu2',
+ desc: "Verify the ability of the SUT to appropriately respond in the event of positive delivery notification. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite.",
+ sutEdge: false,
+ criteria: "['h2-11']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module is able to successfully process a message from the ETT (as Sending Edge) to a valid address. The ETT (as Destination HISP) responds with a Processed MDN and Dispatched MDN within the expected time period. \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).",
+ 'Conformance Test Details':
+ 'The HISP sends only one positive delivery status notification message back to the EDGE.',
+ 'Expected Test Results':
+ 'The Health IT Module sends a positive delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 43',
+ id: '43mu2',
+ ID: '43mu2',
+ desc: "Verify the ability of the SUT to appropriately provide a delivery failure message if it is unable to deliver the message to the destination. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response.",
+ sutEdge: false,
+ criteria: "['h2-12']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module receives a message from the ETT (as Sending HISP) and is unable to deliver the message to its final destination (ETT as Destination Edge). \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).\n Expected outcome: '...Final-Recipient: rfc822; processedfailure@ttpedge.sitenv.org, Original-Recipient: rfc822; processedfailure@ttpedge.sitenv.org, Original-Message-ID: <681247680.299.1498573532567.JavaMail.root@ip-172-31-46-193>, Disposition: automatic-action/MDN-sent-automatically;failure, Failure: Failure MDN'",
+ 'Conformance Test Details':
+ 'The Health IT Module delivers a Processed MDN to the ETT (as Sending HISP) followed by a delivery failure message to the ETT (as Sending HISP) after the wait time has exceeded',
+ 'Expected Test Results':
+ 'The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 44',
+ id: '44mu2',
+ ID: '44mu2',
+ desc: "Verify the ability of the receiving system to appropriately respond in the event of a message timeout failure. ETT will send a message via XDR to the SUT. If the SUT's final response is delivered synchronously, that message will be saved in the logs (click 'Logs'). If the SUT's final response is delivered asynchronously: 1) wait until the SUT's message has been sent and the ETT's response has been received, 2) click the Pending Refresh button to continue, 3) the logs for the asynchronous communication will then be available. The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response.",
+ sutEdge: false,
+ criteria: "['h2-12']",
+ sutHisp: true,
+ sutRole: 'receiver',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages.',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ { name: 'Timeout', hoverlabel: 'Timeout', key: 'timeout', type: 'string' },
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'SUT (HISP) outgoing SMTP address.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Outgoing (ETT --> SUT) Direct From Address',
+ key: 'outgoing_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': 'XDR Receive',
+ 'Data Flow in Direct': 'HISP receives an XDR message from the Edge',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'Included',
+ 'SUT: Sender/ Receiver': 'Receiver (HISP - SUT)',
+ 'Test Tool: Sender / Receiver': 'Sender (Test Tool)',
+ 'Purpose/Description':
+ "The Health IT Module receives a message from the ETT (as Sending HISP) and is unable to deliver the message to its final destination (ETT as Destination Edge). \n Note: When the SUT (HISP) receives the MDN (from the 'direct:to' and hence RCPT TO from the Direct communication), the MAIL FROM of the MDN will be 'direct:to' - since the 'direct:to' endpoint is sending the MAIL FROM. The ETT hardcodes 'direct:to' based on the test case, normally is not needed. \n Outgoing (ETT --> SUT) Direct From Address:Note: MDN Direct from address in the 'direct:from' address the XDR MDN. ETT will use in creating the SOAP XDR transaction for this test. In turn this is destined to become the SMTP MAIL FROM for the ensuing Direct Communication between the SUT HISP to the ETT HISP (the 'direct:to' becomes the RCPT TO).\n The Timeout parameter is amount of time the SUT will wait before sending a Failed MDN, this parameter should be the SUT default plus 5 minutes (N + 5 minutes). If a value is not defined, the test default is 65 minutes \n Expected outcome: \n--uuid:184c5b14-5eb3-4192-b5a4-3ca7e0758305 Content-Type: message/delivery-status; name=status.dat Content-Transfer-Encoding: binary Content-ID: <67bf0371-bf9a-4d39-b2b1-2a0d94ac3b41-24@urn:ihe:iti:xds-b:2007> \n Reporting-MTA: dns;Security Agent X-Original-Message-ID: <985848505.23.1500407627229.JavaMail.root@ip-172-31-46-193> \n Action: failed Final-Recipient: rfc822;delaydispatched5@ttpedgetest.sitenv.org Status: 5.0.0",
+ 'Conformance Test Details':
+ 'The Health IT Module delivers a Processed MDN to the ETT (as Sending HISP) followed by a delivery failure message to the ETT (as Sending HISP) due to the bad address',
+ 'Expected Test Results':
+ 'The Health IT Module sends a negative delivery status notification message to the ETT (as Sending Edge) using XDR profile',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 48',
+ id: '48mu2',
+ ID: '48mu2',
+ desc: "Verifies the ability of the sending system to send messages with unique message-IDs. Hit 'RUN' and then the sending system will send three messages with unique identifiers to the endpoint provided. When all three messages have been completely sent, press the 'Pending Refresh' button. (Message Tracking Using \"Implementation Guide for Delivery Notification\")",
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': '',
+ 'Data Flow in Direct': '',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': '',
+ 'Purpose/Description': 'Test to validate that the Edge system is able to create messages with unique message id.',
+ 'Conformance Test Details': '',
+ 'Expected Test Results': 'Edge system creates each message with a unique message id with no duplicates.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 49',
+ id: '49mu2',
+ ID: '49mu2',
+ desc: 'Verify the ability of the sending system to correctly use a direct address block per the section 4.0 XDR and XDM Messaging for Direct v1.0 and per section 1.3 of the "Implementation Guide for Delivery Notification for Direct v1.0". The SOAP header will be inspected for the appropriate content.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ criteria: "['b1-1']",
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ ],
+ 'Test Focus': '',
+ 'Data Flow in Direct': '',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': '',
+ 'Purpose/Description':
+ 'Test to validate that the Edge system is able to generate the direct address block header including delivery notifications element.',
+ 'Conformance Test Details': '',
+ 'Expected Test Results':
+ 'Edge system creates the direct address block including the disposition notifications header.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 50a',
+ id: '50amu2',
+ ID: '50amu2',
+ desc: ' Verify the ability of the sending system to correctly handle the case of sending XDR messages to valid recipients. The SUT is expected to appropriately track success messages.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ expectedMDN: true,
+ 'Test Focus': '',
+ 'Data Flow in Direct': '',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': '',
+ 'Purpose/Description':
+ 'The SUT should send the test message to Testcase50a@ttpedge.sitenv.org. Verify the ability of the sending system to correctly handle the case of sending XDR messages to valid recipients.',
+ 'Conformance Test Details': '',
+ 'Expected Test Results': 'Edge system receives and processes a positive (success) delivery status notification.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+ {
+ name: 'XDR MT Test 50b',
+ id: '50bmu2',
+ ID: '50bmu2',
+ desc: ' Verify the ability of the sending system to correctly handle the case of sending XDR messages to invalid recipients. The SUT is expected to appropriately track failure messages. Failure messages to invalid recipients have to be processed/tracked appropriately by the edge system and has to be made available for testing purposes.',
+ sutEdge: true,
+ sutHisp: false,
+ sutRole: 'sender',
+ status: 'configure',
+ inputs: [
+ {
+ name: 'Direct From Address',
+ hoverlabel: 'Direct From Address: SUT (HISP) outgoing SMTP address (or) MDN.',
+ key: 'direct_from',
+ type: 'string',
+ },
+ {
+ name: 'Endpoint',
+ hoverlabel: 'Receiving endpoint of the SUT for XDR SOAP messages',
+ key: 'targetEndpointTLS',
+ type: 'string',
+ },
+ ],
+ expectedMDN: true,
+ 'Test Focus': '',
+ 'Data Flow in Direct': '',
+ 'Metadata Included': 'N/A',
+ 'Direct Address Block': 'N/A',
+ 'SUT: Sender/ Receiver': 'Sender (Edge - SUT)',
+ 'Test Tool: Sender / Receiver': '',
+ 'Purpose/Description':
+ 'The SUT should send the test message to Testcase50b@ttpedge.sitenv.org. Verify the ability of the sending system to correctly handle the case of sending XDR messages to invalid recipients.',
+ 'Conformance Test Details': '',
+ 'Expected Test Results':
+ 'Edge system successfully processes the invalid MDN received for tracking. The Edge SUT should display the event in the log for tracking.',
+ 'Required / Conditional per Direct Edge Protocol Guide': 'R',
+ 'Direct Edge Protocol Guide 1.1 RTM Reference': 1.1,
+ 'Test Data IDs': null,
+ },
+]
+export default testCases
diff --git a/src/components/direct/register/Register.tsx b/src/components/direct/register/Register.tsx
new file mode 100644
index 00000000..7e6567a8
--- /dev/null
+++ b/src/components/direct/register/Register.tsx
@@ -0,0 +1,82 @@
+import Link from 'next/link'
+import BannerBox from '../../shared/BannerBox'
+import styles from '../../shared/styles.module.css'
+import { Box, Button, Container, TextField, Typography } from '@mui/material'
+import palette from '@/styles/palette'
+const Register = () => {
+ return (
+ <>
+ {/* Global Header */}
+
+ Direct
+ ,
+
+ Register
+ ,
+ ]}
+ heading={'Register a Direct Email Address'}
+ description={
+ <>
+ Enter your Direct (From) email address, this will be used to send a validation report to a normal email
+ account. The validation reports are sent back to the email account for review by the user during testing.
+ This panel allows the user to register their contact email account and link one or more Direct (From)
+ account to it. Direct messages sent from a non-registered Direct (From) address will not be validated nor
+ reported on.
+
+ }
+ />
+
+ {/* Main Content */}
+
+
+
+ Enter an email address to get started then select add.
+
+
+
+
+
+
+ Manage Your Contact Email Addresses
+
+ {' '}
+
+
+
+
+
+ {/* To-Do: List email addressess and delete email addresses with funtionality*/}
+
+ Group Members
+
+
+
+
+
+ )
+}
+
+export default Register
diff --git a/src/components/direct/send-direct/DirectForm.tsx b/src/components/direct/send-direct/DirectForm.tsx
new file mode 100644
index 00000000..57b35dc3
--- /dev/null
+++ b/src/components/direct/send-direct/DirectForm.tsx
@@ -0,0 +1,294 @@
+import {
+ Box,
+ Button,
+ Container,
+ Divider,
+ FormControlLabel,
+ FormGroup,
+ InputAdornment,
+ MenuItem,
+ Stack,
+ Switch,
+ TextField,
+ Tooltip,
+ Typography,
+} from '@mui/material'
+import DragandDropFile from '@components/shared/DragandDropFile'
+import HelpIcon from '@mui/icons-material/Help'
+import React, { useEffect, useState } from 'react'
+import _ from 'lodash'
+
+const documentDropdown = [
+ {
+ value: 'CCDA_Ambulatory.xml',
+ label: 'CCDA_Ambulatory.xml',
+ },
+ {
+ value: 'CCDA_AMB.ZIP',
+ label: 'CCDA_AMB.ZIP',
+ },
+ {
+ value: 'CCDA_Inpatient.xml',
+ label: 'CCDA_Inpatient.xml',
+ },
+ {
+ value: 'CCDA_INPATIENT_IN_XDM.ZIP',
+ label: 'CCDA_INPATIENT_IN_XDM.ZIP',
+ },
+ {
+ value: 'TOC_XDM_FULL_METADATA.ZIP',
+ label: 'TOC_XDM_FULL_METADATA.ZIP',
+ },
+ {
+ value: 'TOC_XDM_LIMITED_METADATA.ZIP',
+ label: 'TOC_XDM_LIMITED_METADATA.ZIP',
+ },
+]
+
+export type certProps = { value: string; label: string }
+export type algorithmProps = { label: string; value: string }
+export interface DirectFormProps {
+ version: string
+ certificateDropdown: certProps[]
+ algorithmDropdown: algorithmProps[]
+}
+
+const DirectForm = ({ version, certificateDropdown, algorithmDropdown }: DirectFormProps) => {
+ const [formErrors, setFormErrors] = useState({})
+ const [formValues, setFormValues] = useState({})
+ const [disableSendButton, setDisableSendButton] = React.useState(true)
+ /* TO-DO: Form submission, this would change when we work on functionality */
+ const handleSubmit = (e: React.FormEvent) => {
+ const { name, value } = e.currentTarget
+ setFormValues({
+ ...formValues,
+ [name]: value,
+ })
+ console.log(formValues)
+ }
+
+ /* Validation*/
+ const handleValidation = (e: React.ChangeEvent) => {
+ let errors = {}
+ const { name, value } = e.target
+
+ if (value === '') {
+ errors = { ...errors, [name]: 'Email Address is required' }
+ }
+ if (!/^[a-zA-Z0-9._:$!%-]+@[a-zA-Z0-9.-]+.[a-zA-Z]$/.test(value)) {
+ errors = { ...errors, [name]: 'Please enter a valid email' }
+ }
+ setFormValues({
+ ...formValues,
+ [name]: value,
+ })
+ setFormErrors(errors)
+ }
+
+ useEffect(() => {
+ if (_.has(formValues, 'fromEmail') && _.has(formValues, 'toEmail') && _.isEmpty(formErrors)) {
+ setDisableSendButton(false)
+ }
+ }, [disableSendButton, formErrors, formValues])
+
+ return (
+
+
+
+ Step 1
+
+
+ Enter the fields below to send your direct message
+
+
+
+
+ @ett.healthit.gov
+
+ ),
+ type: 'email',
+ }}
+ required
+ onChange={handleValidation}
+ />
+
+
+
+
+ {documentDropdown.map((option) => (
+
+ ))}
+
+
+ {version === 'v12' && (
+ }
+ label="Message Format: Wrapped"
+ name="wrapped"
+ />
+ )}
+ {version === 'v13' && (
+ }
+ label="Message Format: Wrapped"
+ name="wrapped"
+ />
+ )}
+
+
+
+
+
+
+
+ Upload your own C-CDA file
+
+
+
+
+
+
+
+
+
+
+ Step 2
+
+
+ Signing
+
+
+
+
+ {certificateDropdown.map((option) => (
+
+ ))}
+
+
+
+ or select message with invalid digest (message which had been altered)
+
+
+ }
+ label="Invalid Digest"
+ name="invalidDigest"
+ />
+
+
+
+
+ {algorithmDropdown.map((option) => (
+
+ ))}
+
+
+
+
+ Encryption Certificate
+
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default DirectForm
diff --git a/src/components/direct/send-direct/SendDirect.tsx b/src/components/direct/send-direct/SendDirect.tsx
new file mode 100644
index 00000000..33f5b92b
--- /dev/null
+++ b/src/components/direct/send-direct/SendDirect.tsx
@@ -0,0 +1,35 @@
+'use client'
+import BannerBox from '@/components/shared/BannerBox'
+import Link from 'next/link'
+import styles from '@shared/styles.module.css'
+import TabsComponent, { TabInputs } from '@/components/shared/TabsComponent'
+import Version13 from './Version13Tab'
+import Version12 from './Version12Tab'
+
+const SendDirect = () => {
+ const sendDirectTabs: TabInputs[] = [
+ { tabName: 'VERSION V1.3', tabIndex: 0, tabPanel: },
+ { tabName: 'VERSION V1.2', tabIndex: 1, tabPanel: },
+ ]
+ return (
+ <>
+ {/* Global Header */}
+
+ Direct
+ ,
+
+ Direct Message
+ ,
+ ]}
+ heading={'Send Direct Message '}
+ description={<>Send a Direct message from this tool to a HISP of your choosing. Need more text here}
+ />
+ {/* Main Content */}
+
+
+ )
+}
+
+export default SendDirect
diff --git a/src/components/direct/send-direct/Version12Tab.tsx b/src/components/direct/send-direct/Version12Tab.tsx
new file mode 100644
index 00000000..e1162df0
--- /dev/null
+++ b/src/components/direct/send-direct/Version12Tab.tsx
@@ -0,0 +1,21 @@
+import DirectForm, { algorithmProps, certProps } from './DirectForm'
+
+const certificateDropdownV12: certProps[] = [
+ { value: 'GOOD', label: 'GOOD_CERT' },
+ { value: 'INVALID', label: 'INVALID_CERT' },
+ { value: 'EXPIRED', label: 'EXPIRED_CERT' },
+ { value: 'DIFF', label: 'DIFFERENT_TRUST_ANCHOR' },
+ { value: 'AIA', label: 'BAD_AIA' },
+]
+
+const algorithmDropdownV12: algorithmProps[] = [
+ { value: 'sha1', label: 'SHA-1' },
+ { value: 'sha256', label: 'SHA-256' },
+]
+const Version12 = () => {
+ return (
+
+ )
+}
+
+export default Version12
diff --git a/src/components/direct/send-direct/Version13Tab.tsx b/src/components/direct/send-direct/Version13Tab.tsx
new file mode 100644
index 00000000..2b6dc3f7
--- /dev/null
+++ b/src/components/direct/send-direct/Version13Tab.tsx
@@ -0,0 +1,39 @@
+import React from 'react'
+import DirectForm, { algorithmProps, certProps } from './DirectForm'
+
+const certificateDropdown: certProps[] = [
+ { value: 'GOOD_CERT', label: 'GOOD_CERT' },
+ { value: 'INVALID_CERT', label: 'INVALID_CERT' },
+ { value: 'EXPIRED_CERT', label: 'EXPIRED_CERT' },
+ { value: 'DIFFERENT_TRUST_ANCHOR', label: 'DIFFERENT_TRUST_ANCHOR' },
+ { value: 'BAD_AIA', label: 'BAD_AIA' },
+ { value: 'WILD_CARD_DOMAIN_CERT', label: 'WILD_CARD_DOMAIN_CERT' },
+ { value: 'CERT_WITH_EMAIL_ADDRESS', label: 'CERT_WITH_EMAIL_ADDRESS' },
+ { value: 'CERT_LESS_THAN_2048_BITS', label: 'CERT_LESS_THAN_2048_BITS' },
+ { value: 'CERT_WITH_NO_CRL', label: 'CERT_WITH_NO_CRL' },
+ { value: 'CERT_WITH_NO_NOTBEFORE_ATTR', label: 'CERT_WITH_NO_NOTBEFORE_ATTR' },
+ { value: 'CERT_WITH_NO_NOTAFTER_ATT', label: 'CERT_WITH_NO_NOTAFTER_ATT' },
+ { value: 'CERT_WITH_3072_BITS', label: 'CERT_WITH_3072_BITS' },
+ { value: 'CERT_WITH_4096_BITS', label: 'CERT_WITH_4096_BITS' },
+]
+const algorithmDropdown: algorithmProps[] = [
+ { value: 'SHA-256', label: 'SHA-256' },
+ { value: 'SHA-384', label: 'SHA-384' },
+ { value: 'SHA-512', label: 'SHA-512' },
+ {
+ value: 'Optimal Asymmetric Encryption Padding (OAEP) for RSA encryption and decryption',
+ label: 'Optimal Asymmetric Encryption Padding (OAEP) for RSA encryption and decryption',
+ },
+ { value: 'ECDSA with P-256', label: 'ECDSA with P-256' },
+ { value: 'ECDSA with SHA-256', label: 'ECDSA with SHA-256' },
+ { value: 'ECDSA with P-384', label: 'ECDSA with P-384' },
+ { value: 'ECDSA with SHA-384', label: 'ECDSA with SHA-384' },
+ { value: 'AES with CBC', label: 'AES with CBC' },
+ { value: 'AES with GCM', label: 'AES with GCM' },
+]
+
+const Version13 = () => {
+ return
+}
+
+export default Version13
diff --git a/src/components/direct/shared/BulletList.tsx b/src/components/direct/shared/BulletList.tsx
new file mode 100644
index 00000000..002ffd22
--- /dev/null
+++ b/src/components/direct/shared/BulletList.tsx
@@ -0,0 +1,16 @@
+import palette from '@/styles/palette'
+
+const bulletedList = (style: string) => {
+ const styledBullet = {
+ listStyleType: style,
+ ml: 4,
+ [`& li.MuiListItem-root::marker`]: {
+ width: '1em',
+ fontSize: '14px',
+ color: palette.primary,
+ },
+ }
+ return styledBullet
+}
+
+export default bulletedList
diff --git a/src/components/direct/shared/CertificateCard.tsx b/src/components/direct/shared/CertificateCard.tsx
new file mode 100644
index 00000000..790b6a82
--- /dev/null
+++ b/src/components/direct/shared/CertificateCard.tsx
@@ -0,0 +1,49 @@
+import * as React from 'react'
+import Card from '@mui/material/Card'
+import CardContent from '@mui/material/CardContent'
+import CardMedia from '@mui/material/CardMedia'
+import Typography from '@mui/material/Typography'
+import { Button, CardActions } from '@mui/material'
+import Image from 'next/image'
+import ArrowForwardIcon from '@mui/icons-material/ArrowDownward'
+export interface CertificateCardProps {
+ title: string
+ cardImage: string
+ cardHeader: string
+ description: string
+}
+const CertificateCard = ({ title, cardImage, cardHeader, description }: CertificateCardProps) => {
+ return (
+
+
+
+
+
+
+ {cardHeader}
+
+
+ {description}
+
+
+
+ }>
+ DOWNLOAD
+
+
+
+ )
+}
+
+export default CertificateCard
diff --git a/src/components/direct/shared/Profile.tsx b/src/components/direct/shared/Profile.tsx
new file mode 100644
index 00000000..ae3ba338
--- /dev/null
+++ b/src/components/direct/shared/Profile.tsx
@@ -0,0 +1,88 @@
+import palette from '@/styles/palette'
+import { Box, TextField, Button, MenuItem, FormGroup, FormControlLabel, Switch } from '@mui/material'
+
+const dropdown = [
+ {
+ value: 'Default Profile',
+ label: 'Default Profile',
+ },
+]
+const Profile = () => {
+ return (
+
+
+ {dropdown.map((option) => (
+
+ ))}
+
+
+
+
+
+
+
+
+
+
+
+ }
+ label="TLS REQUIRED"
+ name="tlsRequired"
+ />
+
+
+
+
+
+
+
+
+
+
+ )
+}
+export default Profile
diff --git a/src/components/direct/shared/SMTPTestCard.tsx b/src/components/direct/shared/SMTPTestCard.tsx
new file mode 100644
index 00000000..80b85b79
--- /dev/null
+++ b/src/components/direct/shared/SMTPTestCard.tsx
@@ -0,0 +1,50 @@
+import { Box, Button, Card, CardContent, CardHeader, Divider, Typography } from '@mui/material'
+import InfoIcon from '@mui/icons-material/Info'
+export interface TestCardProps {
+ cardHeader: string
+ cardContent: string
+}
+
+const TestCard = ({ cardHeader, cardContent }: TestCardProps) => {
+ return (
+
+
+
+
+ {cardContent}
+
+
+
+
+
+ CCDA Document Type
+
+
+
+
+
+
+
+
+
+
+ )
+}
+export default TestCard
diff --git a/src/components/direct/test-by-criteria/B1Tab.tsx b/src/components/direct/test-by-criteria/B1Tab.tsx
new file mode 100644
index 00000000..011c6f69
--- /dev/null
+++ b/src/components/direct/test-by-criteria/B1Tab.tsx
@@ -0,0 +1,98 @@
+import {
+ Box,
+ Card,
+ CardContent,
+ Container,
+ FormControl,
+ InputLabel,
+ MenuItem,
+ Select,
+ SelectChangeEvent,
+ Typography,
+} from '@mui/material'
+import Profile from '../shared/Profile'
+import SMTPTestCard from '../shared/SMTPTestCard'
+import palette from '@/styles/palette'
+import * as React from 'react'
+import { useEffect } from 'react'
+
+const B1Component = () => {
+ const [option, setOption] = React.useState('')
+ const [showTestCard, setShowTestCard] = React.useState(false)
+ const handleChange = (event: SelectChangeEvent) => {
+ setOption(event.target.value as string)
+ }
+
+ useEffect(() => {
+ if (option !== '') {
+ setShowTestCard(true)
+ }
+ }, [option])
+ const dropdown = [
+ {
+ value: 'A',
+ label: 'A',
+ },
+ {
+ value: 'B',
+ label: 'B',
+ },
+ {
+ value: 'C',
+ label: 'C',
+ },
+ {
+ value: 'D',
+ label: 'D',
+ },
+ ]
+ return (
+
+
+
+
+
+
+
+ Use the menu to select what sub criteria you want to test for.
+
+
+
+ Choose a sub category
+
+
+
+
+
+
+
+
+
+
+
+ {showTestCard && (
+
+ )}
+
+
+
+ )
+}
+export default B1Component
diff --git a/src/components/direct/test-by-criteria/H1Tab.tsx b/src/components/direct/test-by-criteria/H1Tab.tsx
new file mode 100644
index 00000000..4ee781da
--- /dev/null
+++ b/src/components/direct/test-by-criteria/H1Tab.tsx
@@ -0,0 +1,97 @@
+import {
+ Box,
+ Typography,
+ MenuItem,
+ FormControl,
+ InputLabel,
+ Select,
+ SelectChangeEvent,
+ Card,
+ CardContent,
+ Container,
+} from '@mui/material'
+import Profile from '../shared/Profile'
+import SMTPTestCard from '../shared/SMTPTestCard'
+import palette from '@/styles/palette'
+import React, { useEffect } from 'react'
+
+const H1Component = () => {
+ const [option, setOption] = React.useState('')
+ const [showTestCard, setShowTestCard] = React.useState(false)
+ const handleChange = (event: SelectChangeEvent) => {
+ setOption(event.target.value as string)
+ }
+
+ useEffect(() => {
+ if (option !== '') {
+ setShowTestCard(true)
+ }
+ }, [option])
+ const dropdown = [
+ {
+ value: 'A',
+ label: 'A',
+ },
+ {
+ value: 'B',
+ label: 'B',
+ },
+ {
+ value: 'C',
+ label: 'C',
+ },
+ {
+ value: 'D',
+ label: 'D',
+ },
+ ]
+ return (
+
+
+
+
+
+
+
+ Use the menu to select what sub criteria you want to test for.
+
+
+
+ Choose a sub category
+
+
+
+
+
+
+
+
+
+
+
+ {showTestCard && (
+
+ )}
+
+
+
+ )
+}
+export default H1Component
diff --git a/src/components/direct/test-by-criteria/H2Tab.tsx b/src/components/direct/test-by-criteria/H2Tab.tsx
new file mode 100644
index 00000000..4faf7aa6
--- /dev/null
+++ b/src/components/direct/test-by-criteria/H2Tab.tsx
@@ -0,0 +1,124 @@
+import {
+ Box,
+ Typography,
+ MenuItem,
+ Card,
+ CardContent,
+ Container,
+ FormControl,
+ InputLabel,
+ Select,
+ SelectChangeEvent,
+} from '@mui/material'
+import Profile from '../shared/Profile'
+import SMTPTestCard from '../shared/SMTPTestCard'
+import palette from '@/styles/palette'
+import * as React from 'react'
+import { useEffect } from 'react'
+
+const H2Component = () => {
+ const [option, setOption] = React.useState('')
+ const [showTestCard, setShowTestCard] = React.useState(false)
+ const handleChange = (event: SelectChangeEvent) => {
+ setOption(event.target.value as string)
+ }
+ useEffect(() => {
+ if (option !== '') {
+ setShowTestCard(true)
+ }
+ }, [option])
+ const dropdown = [
+ {
+ value: 'A',
+ label: 'A',
+ },
+ {
+ value: 'B',
+ label: 'B',
+ },
+ {
+ value: 'C',
+ label: 'C',
+ },
+ {
+ value: 'D',
+ label: 'D',
+ },
+ ]
+ return (
+
+
+
+
+
+
+
+ Use the menu to select what sub criteria you want to test for.
+
+
+
+ Choose a sub category
+
+
+
+
+
+
+
+
+
+
+ Use the menu to select what sub criteria you want to test for.
+
+
+
+ Choose a sub category
+
+
+
+
+
+
+
+
+
+
+
+ {showTestCard && (
+
+ )}
+
+
+
+ )
+}
+export default H2Component
diff --git a/src/components/direct/test-by-criteria/TestByCriteria.tsx b/src/components/direct/test-by-criteria/TestByCriteria.tsx
new file mode 100644
index 00000000..606b4d46
--- /dev/null
+++ b/src/components/direct/test-by-criteria/TestByCriteria.tsx
@@ -0,0 +1,41 @@
+'use client'
+import * as React from 'react'
+import BannerBox from '@shared/BannerBox'
+import B1Component from './B1Tab'
+import H1Component from './H1Tab'
+import H2Component from './H2Tab'
+import Link from 'next/link'
+import styles from '@shared/styles.module.css'
+import TabsComponent, { TabInputs } from '@/components/shared/TabsComponent'
+export interface criteriaProps {
+ selectedTab: string
+}
+
+const TestByCriteria = ({ selectedTab }: criteriaProps) => {
+ const criteriaTabs: TabInputs[] = [
+ { tabName: 'B1', tabIndex: 0, tabPanel: },
+ { tabName: 'H1', tabIndex: 1, tabPanel: },
+ { tabName: 'H2', tabIndex: 2, tabPanel: },
+ ]
+
+ return (
+ <>
+ {/* Global Header */}
+
+ Direct
+ ,
+
+ Test By Criteria
+ ,
+ ]}
+ heading={'Test By Criteria'}
+ description={<>New Helper Text}
+ />
+
+
+ )
+}
+
+export default TestByCriteria
diff --git a/src/components/direct/transport-tool/OwnContentTab.tsx b/src/components/direct/transport-tool/OwnContentTab.tsx
new file mode 100644
index 00000000..086edfee
--- /dev/null
+++ b/src/components/direct/transport-tool/OwnContentTab.tsx
@@ -0,0 +1,30 @@
+import DragandDropFile from '@/components/shared/DragandDropFile'
+import palette from '@/styles/palette'
+import { Box, TextField, Stack, Typography, Button } from '@mui/material'
+
+const OwnContentTab = () => {
+ return (
+
+
+
+
+
+ Select a Local C-CDA File to Send:
+
+
+
+
+
+
+ )
+}
+
+export default OwnContentTab
diff --git a/src/components/direct/transport-tool/PrecannedContentTab.tsx b/src/components/direct/transport-tool/PrecannedContentTab.tsx
new file mode 100644
index 00000000..ed7cb815
--- /dev/null
+++ b/src/components/direct/transport-tool/PrecannedContentTab.tsx
@@ -0,0 +1,46 @@
+import palette from '@/styles/palette'
+import { Box, TextField, Button, MenuItem } from '@mui/material'
+
+const fileDropdown = [
+ {
+ value: ' ',
+ label: 'select one',
+ },
+]
+
+const PrecannedContentTab = () => {
+ return (
+
+
+
+
+ {fileDropdown.map((option) => (
+
+ ))}
+
+
+
+
+ )
+}
+
+export default PrecannedContentTab
diff --git a/src/components/direct/transport-tool/ReceiveMessageSITE.tsx b/src/components/direct/transport-tool/ReceiveMessageSITE.tsx
new file mode 100644
index 00000000..b34e4659
--- /dev/null
+++ b/src/components/direct/transport-tool/ReceiveMessageSITE.tsx
@@ -0,0 +1,51 @@
+'use client'
+import { Typography, List, ListItem } from '@mui/material'
+import bulletedList from '../shared/BulletList'
+import TabsComponent, { TabInputs } from '@/components/shared/TabsComponent'
+import PrecannedContentTab from './PrecannedContentTab'
+import OwnContentTab from './OwnContentTab'
+
+const ReceeiveMessageSITE = () => {
+ const contentTabs: TabInputs[] = [
+ { tabName: 'PRECANNED CONTENT', tabIndex: 0, tabPanel: },
+ { tabName: 'CHOOSE YOUR OWN CONTENT', tabIndex: 1, tabPanel: },
+ ]
+
+ return (
+ <>
+
+ Send messages from the Sandbox to your system
+
+
+
+
+ Choose your own content: Developers can use their own files as the payload of the Direct
+ message sent from the Sandbox. This provides the ability to verify the file they chosen and that the
+ contents were decrypted appropriately.
+
+
+
+
+ Choose pre-canned content: Provides a list of files that you can choose from as the payload
+ of the Direct message.
+
+
+
+
+ Enter your end point name: The name of the Direct address where you would like to receive
+ the message. Ensure that the Trust Anchor corresponding to the end point has already been uploaded.
+
+
+
+
+ Once the above fields are populated, hit the send message button. You will receive a message from
+ provider1@direct.site.healthit.gov to your system with the content you have uploaded.
+
+
+
+
+
+ )
+}
+
+export default ReceeiveMessageSITE
diff --git a/src/components/direct/transport-tool/SendMessageDirect.tsx b/src/components/direct/transport-tool/SendMessageDirect.tsx
new file mode 100644
index 00000000..383c0e1a
--- /dev/null
+++ b/src/components/direct/transport-tool/SendMessageDirect.tsx
@@ -0,0 +1,47 @@
+import palette from '@/styles/palette'
+import { Typography, List, ListItem, Box, Button, TextField } from '@mui/material'
+import bulletedList from '../shared/BulletList'
+
+const SendMessageDirect = () => {
+ return (
+ <>
+
+ When you are part of the Direct Trust Production Bundle and would like to validate your Direct installation,
+ send Direct messages to the end point listed below
+
+
+
+ interop@direct.hhs.gov
+
+
+
+ Upon successful receipt of the message, the Direct Transport Test Tool will send an MDN(Message Disposition
+ Notification) back to the sender’s email address. The content of the message can be anything and is not
+ validated or used by the SITE. To validate if a message was received from your test system, enter your Direct
+ From address which you used to send the message below and search for messages. The test tool will display the
+ last message received from the Direct From address entered if any exist.
+
+
+
+
+ Verify your message was received
+
+
+
+
+
+ )
+}
+
+export default SendMessageDirect
diff --git a/src/components/direct/transport-tool/SendMessageSITE.tsx b/src/components/direct/transport-tool/SendMessageSITE.tsx
new file mode 100644
index 00000000..d97b8ec3
--- /dev/null
+++ b/src/components/direct/transport-tool/SendMessageSITE.tsx
@@ -0,0 +1,45 @@
+import palette from '@/styles/palette'
+import { Typography, List, ListItem, Box, Button, TextField } from '@mui/material'
+import bulletedList from '../shared/BulletList'
+
+const SendMessageSITE = () => {
+ return (
+ <>
+
+ When you exchanged your Trust Anchors with SITE and want to validate your Direct installation, send Direct
+ messages to the end point listed below
+
+
+
+ provider1@direct.site.healthit.gov
+
+
+
+ {
+ "Upon successful receipt of the message, the Direct Transport Test Tool will send an MDN(Message Disposition Notification) back to the sender's email address. The content of the message can be anything and is not validated or used by the SITE. To validate if a message was received from your test system, enter your Direct From address which you used to send the message below and search for messages. The test tool will display the last message received from the Direct From address entered if any exist."
+ }
+
+
+
+
+ Verify your message was received
+
+
+
+
+
+ )
+}
+
+export default SendMessageSITE
diff --git a/src/components/direct/transport-tool/TransportTestTool.tsx b/src/components/direct/transport-tool/TransportTestTool.tsx
new file mode 100644
index 00000000..a4bb6499
--- /dev/null
+++ b/src/components/direct/transport-tool/TransportTestTool.tsx
@@ -0,0 +1,150 @@
+import BannerBox from '@/components/shared/BannerBox'
+import SubMenu, { menuProps } from '@/components/shared/SubMenu'
+import styles from '@/components/shared/styles.module.css'
+import { Container, Box, Card, CardContent, CardHeader, Divider, List, ListItem, Typography } from '@mui/material'
+import Link from 'next/link'
+import bulletedList from '../shared/BulletList'
+import TrustAnchorExchange from './TrustAnchorExchange'
+import SendMessageSITE from './SendMessageSITE'
+import SendMessageDirect from './SendMessageDirect'
+import ReceeiveMessageSITE from './ReceiveMessageSITE'
+
+const menuItems: menuProps[] = [
+ { heading: 'Overview', href: '#overview' },
+ { heading: 'Trust Anchor Exchange Instructions', href: '#trustAnchor' },
+ { heading: 'Send Direct Message using SITE Trust Anchor', href: '#sendMessageSITE' },
+ { heading: 'Send Direct Message using Direct Trust Production Bundle', href: '#sendMessageDirect' },
+ { heading: 'Receive Direct Message from SITE', href: '#receiveMessageSITE' },
+]
+const TransportTestTool = () => {
+ return (
+ <>
+ {/* Global Header */}
+
+ Direct
+ ,
+
+ Transport Test Tool
+ ,
+ ]}
+ heading={'Direct Transport Test Tool'}
+ description={
+ <>
+ The goal of the SITE Direct Transport test tool is to provide a mechanism for Health IT developers and
+ implementers to test their Direct implementation by sending and receiving messages to and from the SITE
+ Direct test tools.
+
+ }
+ />
+
+ {/* Main Content */}
+
+
+ Prepare to exchange Direct messages with the Sandbox
+
+
+
+
+ {/* Overview */}
+
+
+
+
+
+ Directions
+
+
+
+
+ Publish your Direct certificates (Organization or Address bound) per the{' '}
+ Direct specifications.
+
+
+
+
+ If you are a member of Direct Trust production bundle, you can exchange messages with
+ interop@direct.hhs.gov using instructions provided further below.
+
+
+
+
+ If you are not a member of Direct Trust production bundle, exchange Trust Anchors with SITE
+ following Trust Anchor Exchange Instructions.
+
+
+
+
+ {
+ 'Use the instructions in the "Send Direct Message using SITE Trust Anchor" or "Send Direct Message using Direct Trust Production Bundle" features below to send messages and verify.'
+ }
+
+
+
+
+ {
+ 'Use the information in the "Receive Direct Message" feature below to receive messages from the sandbox to your system.'
+ }
+
+
+
+
+
+ If you encounter any issues using the SITE Direct Transport Sandbox send an email to{' '}
+
+ edge-test-tool@googlegroups.com
+
+
+
+
+ {/* Trust Anchor Exchange Instructions */}
+
+
+
+
+
+
+
+ {/* Send Direct Message using SITE Trust Anchor */}
+
+
+
+
+
+
+
+ {/* Send Direct Message using SITE Trust Anchor */}
+
+
+
+
+
+
+
+ {/* Receive Direct Message from SITE */}
+
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default TransportTestTool
diff --git a/src/components/direct/transport-tool/TrustAnchorExchange.tsx b/src/components/direct/transport-tool/TrustAnchorExchange.tsx
new file mode 100644
index 00000000..280925a3
--- /dev/null
+++ b/src/components/direct/transport-tool/TrustAnchorExchange.tsx
@@ -0,0 +1,55 @@
+import palette from '@/styles/palette'
+import { Typography, List, ListItem, Box, Button, Stack } from '@mui/material'
+import bulletedList from '../shared/BulletList'
+import Link from 'next/link'
+import DragandDropFile from '@/components/shared/DragandDropFile'
+
+const TrustAnchorExchange = () => {
+ return (
+ <>
+
+ Directions
+
+
+
+
+ Download the Trust Anchor for the Sandbox{' '}
+
+ (direct.site.healthit.gov Certificate){' '}
+
+ and import the trust anchor into your trust store.
+
+
+
+
+ Please upload your Trust Anchor by selecting your Trust Anchor. If you need to replace the Trust Anchor,
+ just perform another upload and the previous one will be replaced.
+
+
+
+
+ Uploading the Trust Anchor causes an update to the{' '}
+
+ Trust Bundle
+ {' '}
+ of direct.site.healthit.gov which is refreshed every five minutes and is only used for testing purposes.
+ Once a Trust Anchor is uploaded, users can test with the Direct sandbox after five minutes.
+
+
+
+
+
+
+ Select a Local Trust Anchor Certificate (binary or PEM encoded):
+
+
+
+
+
+
+ )
+}
+
+export default TrustAnchorExchange
diff --git a/src/components/direct/validate/Validate.tsx b/src/components/direct/validate/Validate.tsx
new file mode 100644
index 00000000..e49f5721
--- /dev/null
+++ b/src/components/direct/validate/Validate.tsx
@@ -0,0 +1,89 @@
+'use client'
+import BannerBox from '@/components/shared/BannerBox'
+import styles from '@/components/shared/styles.module.css'
+import { Box, Button, Container, Stack, TextField, Tooltip, Typography } from '@mui/material'
+import Link from 'next/link'
+import DragandDropFile from '@components/shared/DragandDropFile'
+import HelpIcon from '@mui/icons-material/Help'
+import palette from '@/styles/palette'
+
+const Validate = () => {
+ return (
+ <>
+ {/* Global Header */}
+
+ Direct
+ ,
+
+ Validate
+ ,
+ ]}
+ heading={'Validate Direct Message'}
+ description={
+ <>
+ Ensure that your direct messaging system complies with legal and regulatory requirements, including HIPAA
+ regulations in the United States. Stay updated with any changes in the regulations that might impact the way
+ direct messages need to be handled and secured.
+
+ }
+ />
+ {/* Main Content */}
+
+
+
+ Upload your file & enter password to validate
+
+
+
+
+
+
+ Upload your message file
+
+
+
+
+
+
+
+
+
+
+ Upload your certificate file
+
+
+
+
+
+
+
+
+
+
+
+
+ )
+}
+
+export default Validate
diff --git a/src/components/hl7-tools/tempFileForStructure-deleteWhenFilesAdded b/src/components/hl7-tools/tempFileForStructure-deleteWhenFilesAdded
new file mode 100644
index 00000000..e69de29b
diff --git a/src/components/home/DragScrollContainer.tsx b/src/components/home/DragScrollContainer.tsx
new file mode 100644
index 00000000..60fb2fc2
--- /dev/null
+++ b/src/components/home/DragScrollContainer.tsx
@@ -0,0 +1,63 @@
+'use client'
+import { Box } from '@mui/material'
+import React, { useRef, useState } from 'react'
+
+interface DragScrollContainerProps {
+ children: React.ReactNode
+}
+export default function DragScrollContainer(props: DragScrollContainerProps) {
+ const rowPaddingBottom: number = 20
+
+ const containerRef = useRef(null)
+ const [isDragging, setIsDragging] = useState(false)
+ const [startX, setStartX] = useState(0)
+ const [scrollLeft, setScrollLeft] = useState(0)
+
+ const draggableContainerStyles = {
+ display: '-webkit-box',
+ position: 'relative',
+ flexDirection: 'row',
+ width: '100%',
+ overflowX: 'scroll',
+ gap: '48px',
+ cursor: 'grab', // Set the cursor to grab
+ '&:active': {
+ cursor: 'grabbing', // Change cursor to grabbing when clicked
+ },
+ paddingBottom: `${rowPaddingBottom}px`,
+ }
+
+ const startDragging = (e: React.MouseEvent) => {
+ setIsDragging(true)
+ const scrollContainer = containerRef.current as unknown as HTMLElement
+ setStartX(e.pageX - scrollContainer.offsetLeft)
+ setScrollLeft(scrollContainer.scrollLeft)
+ }
+
+ const stopDragging = () => {
+ setIsDragging(false)
+ }
+
+ const handleMouseMove = (e: React.MouseEvent) => {
+ if (!isDragging) return
+ e.preventDefault()
+ const scrollContainer = containerRef.current as unknown as HTMLElement
+ const x = e.pageX - scrollContainer.offsetLeft
+ const walk = x - startX
+ scrollContainer.scrollLeft = scrollLeft - walk
+ }
+
+ return (
+
+ {props.children}
+
+ )
+}
diff --git a/src/components/home/SiteHome.tsx b/src/components/home/SiteHome.tsx
new file mode 100644
index 00000000..0ce8b425
--- /dev/null
+++ b/src/components/home/SiteHome.tsx
@@ -0,0 +1,26 @@
+import BannerBox from '@shared/BannerBox'
+import SiteHomeRows from './SiteHomeRows'
+
+export default function SiteHome() {
+ return (
+
+ {/* Header */}
+
+ The Standards Implementation & Testing Environment (SITE) is a centralized collection of testing tools and
+ resources designed to assist health IT developers and health IT users fully evaluating specific technical
+ standards and maximizing the potential of their health IT implementations. SITE is organized in a collection
+ of sandboxes that provide test tools, sample data, collaboration resources, and useful links.
+
+ }
+ />
+ {/* Main Content */}
+
+
+ )
+}
diff --git a/src/components/home/SiteHomeRows.tsx b/src/components/home/SiteHomeRows.tsx
new file mode 100644
index 00000000..7f2209f4
--- /dev/null
+++ b/src/components/home/SiteHomeRows.tsx
@@ -0,0 +1,248 @@
+import palette from '@/styles/palette'
+import { Box, Container } from '@mui/material'
+import atmSvg from '@public/home/alternative.svg'
+import cCdaSvg from '@public/home/c-cda.svg'
+import cpoeSvg from '@public/home/cpoe.svg'
+import cqmQrdaSvg from '@public/home/cqm-qrda.svg'
+import eRxSvg from '@public/home/erx.svg'
+import phrSvg from '@public/home/phr.svg'
+import directSvg from '@public/home/direct.svg'
+import hl7Svg from '@public/home/hl7.svg'
+import igSvg from '@public/home/ig.svg'
+import iheSvg from '@public/home/ihe.svg'
+import infernoSvg from '@public/home/inferno.svg'
+import lanternSvg from '@public/home/lantern.svg'
+import nistSvg from '@public/home/nist.svg'
+import referenceDataSvg from '@public/home/reference-data.svg'
+import CardWithImageHome from '@shared/CardWithImageHome'
+import SectionHeader from '../shared/SectionHeader'
+import DragScrollContainer from './DragScrollContainer'
+
+export default function SiteHomeRows() {
+ const maxWidth: number = 320
+ const rowPaddingBottom: number = 20
+ const industryTestingResourceRow: number = 350
+ const imageURL: string = '../shared/ONCLogo-backgroundImage.png'
+
+ const containerNoDragStyles = {
+ display: 'flex',
+ flexDirection: 'row',
+ justifyContent: 'space-between',
+ width: '100%',
+ paddingBottom: `${rowPaddingBottom}px`,
+ }
+
+ return (
+ <>
+ {/* TODO:
+ -#Matt: Fix card overlap (in 3rd row only now) on lower res screens
+ -Externalize links (external and routes) here and in nav to constants since there is reuse now
+ */}
+
+
+ {/* Row 1: Scrollable: ONC Certification Tools*/}
+
+
+
+
+
+
+
+
+
+
+
+ {/* Row 2: Scrollable: General Testing Tools*/}
+
+
+
+
+
+
+
+
+ {/* Row 3: Fixed: Industry Testing Resources */}
+
+
+
+
+
+
+
+
+
+ )
+}
diff --git a/src/components/implementation-guide-authoring-tools/tempFileForStructure-deleteWhenFilesAdded b/src/components/implementation-guide-authoring-tools/tempFileForStructure-deleteWhenFilesAdded
new file mode 100644
index 00000000..e69de29b
diff --git a/src/components/nist-conformance-test/tempFileForStructure-deleteWhenFilesAdded b/src/components/nist-conformance-test/tempFileForStructure-deleteWhenFilesAdded
new file mode 100644
index 00000000..e69de29b
diff --git a/src/components/public-health-reporting/PHRHome.tsx b/src/components/public-health-reporting/PHRHome.tsx
new file mode 100644
index 00000000..fbfa171f
--- /dev/null
+++ b/src/components/public-health-reporting/PHRHome.tsx
@@ -0,0 +1,125 @@
+// MUI Imports
+import BannerBox from '../shared/BannerBox'
+import { Box, Container, Divider } from '@mui/material'
+// Global Imports
+import Link from 'next/link'
+// MUI Icons
+import ArrowForwardIcon from '@mui/icons-material/ArrowDownward'
+// Styles
+import palette from '@/styles/palette'
+import SectionHeader from '../shared/SectionHeader'
+import CardWithBorder from '../shared/CardWithBorder'
+// Images
+
+// * Will bring in at a different time
+// const hoverGrow = {
+// transition: 'transform 0.15s ease-in-out',
+// '&:hover': {
+// transform: 'scale3d(1.05, 1.05, 1)',
+// boxShadow: '0px 0px 16px 8px rgba(0,0,0,0.1)',
+// },
+// }
+
+const PHRHome = () => {
+ return (
+
+ {/* Global Header */}
+
+ Public Health Reporting
+
+ }
+ heading={'Public Health Reporting'}
+ description={
+ <>
+ Explore public health reporting and CDA reporting tools, including HL7® CDA® Cancer Registry Reporting
+ Validation Tool for validating cancer-related medical information. Additionally, ensure compliance with
+ HL7® CDA® National Health Care Surveys Validator for testing CDA XML documents. NIST offers specialized
+ test suites like the HL7® v2 Immunization and Syndromic Surveillance Test Suites, along with the Electronic
+ Laboratory Reporting Validation Suite for HIT certification testing.
+
+ }
+ />
+ {/* Main Content */}
+
+ {/* CDA Reporting Header */}
+
+ {/* Other Tools & Resources Content */}
+
+ {/* HL7® CDA® Cancer Registry Reporting Validation Tool*/}
+ }
+ />
+
+ {/* HL7® CDA® National Health Care Surveys Validator */}
+ }
+ />
+ {/* Antimicrobial use and resistance HL7® CDA® validato*/}
+ }
+ />
+
+
+ {/* NIST Reporting Header */}
+
+ {/* Other Tools & Resources Content */}
+
+ {/* NIST HL7® v2 Immunization Test Suite Card */}
+ }
+ />
+ {/* NIST HL7® v2 Syndromic Surveillance Test Suite */}
+ }
+ />
+ }
+ />
+
+
+
+ )
+}
+
+export default PHRHome
diff --git a/src/components/public-health-reporting/tempFileForStructure-deleteWhenFilesAdded b/src/components/public-health-reporting/tempFileForStructure-deleteWhenFilesAdded
new file mode 100644
index 00000000..e69de29b
diff --git a/src/components/reference-data/tempFileForStructure-deleteWhenFilesAdded b/src/components/reference-data/tempFileForStructure-deleteWhenFilesAdded
new file mode 100644
index 00000000..e69de29b
diff --git a/src/components/resources/DocsCard.tsx b/src/components/resources/DocsCard.tsx
new file mode 100644
index 00000000..cfdad5ba
--- /dev/null
+++ b/src/components/resources/DocsCard.tsx
@@ -0,0 +1,37 @@
+import * as React from 'react'
+import Card from '@mui/material/Card'
+import Box from '@mui/material/Box'
+import Typography from '@mui/material/Typography'
+import Divider from '@mui/material/Divider'
+
+interface DocsCardProps {
+ header: string
+ content: React.ReactNode
+}
+
+const DocsCard: React.FC = ({ header, content }) => {
+ return (
+
+
+
+ {header}
+
+
+ {content}
+
+
+ )
+}
+
+export default DocsCard
diff --git a/src/components/resources/DocsHome.tsx b/src/components/resources/DocsHome.tsx
new file mode 100644
index 00000000..2fb346dc
--- /dev/null
+++ b/src/components/resources/DocsHome.tsx
@@ -0,0 +1,161 @@
+import { Typography, Container, Link } from '@mui/material'
+import Box from '@mui/material/Box'
+import DocsCard from './DocsCard'
+import BannerBox from '@shared/BannerBox'
+import Divider from '@mui/material/Divider'
+import DocsSubMenu from './DocsSubMenu'
+import VideoItem from './VideoItem'
+
+export default function DocsHome() {
+ return (
+
+
+
+
+
+
+
+
+
+
+ {
+ "Our document library is a comprehensive repository of whitepapers, research reports, guidelines, and informative articles related to ONC SITE. Whether you're looking to stay up-to-date with the latest regulatory changes, delve into technical specifications, or gain insights into the broader landscape of health IT, you'll find a wealth of knowledge at your fingertips."
+ }
+
+
+
+
+
+ {'2015 Test Procedures and Companion Guides '}
+
+ External Link
+
+
+
+
+
+ Local Installation Guide
+
+
+
+
+ {'Installing using the AMI (Amazon Machine Image) '}
+
+ Download
+
+
+
+
+
+ {'2015 Test Procedures and Companion Guides '}
+
+ Download
+
+
+
+
+
+
+ }
+ />
+
+
+
+ {
+ 'For those who prefer visual learning, our video collection offers an engaging way to absorb information '
+ }
+
+
+
+
+ )
+}
+
+export default VideoItem
diff --git a/src/components/resources/WelcomeHeader.tsx b/src/components/resources/WelcomeHeader.tsx
new file mode 100644
index 00000000..be6c45fd
--- /dev/null
+++ b/src/components/resources/WelcomeHeader.tsx
@@ -0,0 +1,36 @@
+import { Box, Breadcrumbs, Container, Typography } from '@mui/material'
+
+export interface WelcomeHeaderProps {
+ heading: string
+ subheading: string
+ description: React.ReactNode
+}
+const WelcomeHeader = ({ heading, subheading, description }: WelcomeHeaderProps) => {
+ return (
+
+
+
+
+ {heading}
+
+
+ {subheading}
+
+
+ {description}
+
+
+
+ )
+}
+
+export default WelcomeHeader
diff --git a/src/components/resources/data/FAQ.json b/src/components/resources/data/FAQ.json
new file mode 100644
index 00000000..fee6a13a
--- /dev/null
+++ b/src/components/resources/data/FAQ.json
@@ -0,0 +1,340 @@
+{
+ "Overview": [
+ {
+ "question": "What is SITE?",
+ "answer": "Discover the core concept and purpose behind SITE, and how it can benefit you or your organization."
+ },
+ {
+ "question": "How do I get started with SITE?",
+ "answer": "Step-by-step guidance on creating an account, setting up your profile, and navigating through SITE's user-friendly interface."
+ },
+ {
+ "question": "What are the key features of SITE?",
+ "answer": "Explore the various tools, functions, and capabilities that SITE offers to help you achieve your goals."
+ },
+ {
+ "question": "How can I connect with other users on SITE?",
+ "answer": "Learn how to build connections, join communities, and engage with fellow SITE users."
+ },
+ {
+ "question": "Is SITE compatible with mobile devices?",
+ "answer": "Find out if SITE is accessible on smartphones and tablets, and how to make the most of the mobile experience."
+ },
+ {
+ "question": "How can I report issues or seek assistance on SITE?",
+ "answer": "Get information on how to report bugs, seek technical support, or contact our customer service team."
+ }
+ ],
+ "Direct": [
+ {
+ "question": "We are trying to use the \"Send a Direct Message\" from the Edge Testing Tool to our implementation and are showing a \"time-out\" status in the Message Status portal.",
+ "answer": "Please ensure that you have installed the Trust Anchor for the ETT into your system."
+ },
+ {
+ "question": "We are testing the \"Send a Direct Message\" functionality as part of our H1 testing: https://ttpedge.sitenv.org/ttp/#/direct/send/. But having an issue with the SHA-256 option. Can you confirm the SHA-256 option is sending the correct hash? It appears to be sending the SHA-1 hash in the message.",
+ "answer": "The first is the hash used to sign the Direct message. The second is the hash that is used in the XD* metadata and refers only to the hash of the attachment itself. These are two separate hashes, calculated independently. \n The first hash is defined in the Direct Applicability Statement. Version 1.0 mentions both SHA-1 and SHA-256 which is why the Direct portion of the ETT tooling allows both to be used for testing. \n The second hash (which is the one from the SOAP body below) is part of the XD* metadata. The definition of the hash slot is in IHE ITI TF Vol 3 Table 4.2.3.2-1 (page 64) http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf. The data type for this hash is \"SHA1\" only. The document metadata is separate from the signing of the Direct message."
+ },
+ {
+ "question": "Why am I not receiving a validation report?",
+ "answer": "Please verify that you have registered your direct address with a corresponding contact address which is where the validation report will be delivered, see https://ttpedge.sitenv.org/ttp/#/direct/register. If you have registered, please check the spam folder to see if the validation report has been held there. Also, the local mailbox (the part before the '@' symbol) portion is case-sensitive;verify that the case in what was registered matches what is being sent."
+ },
+ {
+ "question": "Why can't the ETT find my certificate via LDAP?",
+ "answer": "Please make sure that the LDAP server and port are accessible and not blocked by a firewall. We have been told of issues with older library packages (such as ApacheDS) that were resolved when the library packages were upgraded."
+ },
+ {
+ "question": "The proctor sheet states: “using the health module functionality, the user sends an encrypted and signed direct “wrapped” message payload to the ETT Direct to email address.” Where is the ETT Direct to email address?",
+ "answer": "Use: https://ttpedge.sitenv.org/ttp/#/direct \n- If you are using CCDA R1.1, the scope and direct addresses are in the lower section of the page. Clicking the widget on the right side, for the corresponding address, will copy it to your clipboard. \n- If you are using CCDA R2.1, the direct address will be generated when you select the document you are conforming to. Use the button to select the document and the direct to address will appear underneath it."
+ },
+ {
+ "question": "What is the difference between these two validator sides?: 1. This one is for certification: https://ttpedge.sitenv.org/ttp/#/validators 2. Another that some people have used: https://sitenv.org/sandbox-ccda/ccda-validator",
+ "answer": "The backend is the same; its simply a different interface."
+ },
+ {
+ "question": "In the Direct section of the ETT, sending a direct message to the system under test results in a validation result for the MDNs the SUT produces. I don't believe this case should be sending validation results at all since the testing is around the certificates rather than the MDNs. It looks like the MDNs are being validated as direct messages whether or not the MDN is wrapped. The ETT also seems to be fine with the MDNs in test cases 39, 40 and 41. Should we be receiving validation results for our MDNs in this case?",
+ "answer": "The Direct section of the tool always returns validation reports because it has no programmatic way of knowing what the endpoint is being used for. If the test you are running doesn't need a validation report, the validation report can be ignored. The tool accepts wrapped or unwrapped because of backward compatibility with the previous round of certification where wrapped was optional. Information on whether the message was wrapped or unwrapped is contained in the validation report. Edge test cases won't produce separate validation reports."
+ },
+ {
+ "question": "I'm not getting validation emails from the Direct Testing part of the ETT?",
+ "answer": "The address registered, needs to have a contact email address associated with it."
+ },
+ {
+ "question": "SMTP MT Test 39, 40 and 41 are not working. All have been working for us previously. After clicking \"Run\", I see no attempt at an inbound SMTP connection to my server. I have tried using both a hostname and an IP address?",
+ "answer": "Please upload your trust anchor/public cert using the \"Upload Certificate\" on the left bottom corner of the \"More Info\" section for the these tests."
+ },
+ {
+ "question": "I have imported the invalid trust anchor in DIRECT Server & removed the valid Trust anchor of the ETT. I'm sending an email from the ETT, selecting 'GOOD_CERT' what is the expected functionality. My DIRECT Server is not rejecting this message, though I have an invalid trust anchor in my DIRECT Server.",
+ "answer": "The certificate that you are selecting is the “Signing Certificate”. So a GOOD CERT will send a message with a signing certificate that is valid. The trust anchor, that you have, should dictate whether messages from a particular address is accepted or rejected. If you don’t have the right trust anchor, then the message should be rejected. That is the expected behavior."
+ },
+ {
+ "question": "Not sure what I'm missing. I've uploaded the trust cert and the log shows a message sent to the proper address 1: SENDING EMAIL WITH MESSAGE DISPOSITION NOTIFICATION HEADER TO sand...@direct.... 2: Email sent Successfully 3: Message-ID of the email sent However nothing is hitting our SMTP server. I was able to get messages from the DCDT tests as well as Send Direct Message tests. Am I missing a setup somewhere?",
+ "answer": "Ensure you have uploaded your cert/trust anchor in the left sidebar under profile, here. (https://ttpedge.sitenv.org/ttp/#/hisp/mu2) We see this in the logs:\nWARN 11:03:15,208 | org.nhindirect.stagent.trust.TrustModel | enforce(OutgoingMessage message) - could not trust any certificates for recipient H.......@....com"
+ },
+ {
+ "question": "What are the SMTP MT addresses?",
+ "answer": "The addresses are listed below.Also consult with your ALT for any changes or updates.\nSMTP MT Test 21: processeddispatched6@ttpedge.sitenv.org\nSMTP MT Test 23: badaddresst@ttpds2.siten.org \n SMTP MT Test 24: provider1@direct2.sitenv.org\nSMTP MT Test 25: failure15@ttpds.sitenv.org\nSMTP MT Test 26: nomdn8@ttpedge.sitenv.org\nSMTP MT Test 27: processedonly5@ttpedge.sitenv.org\nSMTP MT Test 29: processeddispatched6@ttpedge.sitenv.org"
+ }
+ ],
+ "SMTP": [
+ {
+ "question": "We are having issues running SMTP Test 8, 14, 18 (Send) and SMTP MT Test 46, the credentials don't work.",
+ "answer": "Please look at the information in the 'More Info' pages for the credentials required to run these tests.\n- SMTP Test 8, 14, 18 (Send): wellformed1@ttpedge.sitenv.org, vendoraccount@ttpds.sitenv.org / vendortesting123\n - SMTP MT Test 46: wellformed14@ttpds.sitenv.org, vendoraccount@ttpds.sitenv.org / vendortesting123"
+ },
+ {
+ "question": "We are testing SMTP Test 8, 14 (Send), per the test in the ETT and following the user guide and it keeps failing. Do we need to install a certificate for this test? We also checked our Direct server and it works with the other Direct protocol tests.",
+ "answer": "This is a SMTP protocol test, not a DIRECT test. If you send using Direct to an SMTP endpoint, it will always fail. A Direct message employs an encryption standard using the certificates published in DNS/LDAP built on the top of SMTP to allow the secure exchange of messages; whereas, plain SMTP does not."
+ },
+ {
+ "question": "The Edge test case SMTP 18 states, the SUT needs to connect to the ETT SMTP server using the credentials vendor...@ttpds.sitenv.org / vendortesting123 and send an email to wellf...@ttpedge.sitenv.org.Is the ETT SMTP server ttpds.siteenv.org?",
+ "answer": "Yes, ttpds.sitenv.org is the SMTP ETT server."
+ },
+ {
+ "question": "SMTP MT Test 1 (Message to Bad Address); I am responding with a DSN rather than an MDN. I am using SMTP for both sending and receiving. I am not using IMAP or POP at this time. Is that acceptable? If not, why not?",
+ "answer": "For these cases, ETT acts as the EDGE SMTP sender (and also the notification SMTP receiver) - and so, the ETT is set up to check for the MDNs in the failure15@ttpds.sitenv.org inbox. The SMTP/SMTP cases are designed such that ETT as an Edge SMTP server sends through the HISP, and expects the HISP to deliver the mail to its inbox failure15@hisp-testing2.nist.gov."
+ },
+ {
+ "question": "I entered my profile information, went to message tracking and followed the instructions for each of the testcases. These test cases are failing: EDGE SMTP MT Test 18(a), EDGE SMTP MT Test 47(a), EDGE SMTP MT Test 45 and EDGE SMTP MT Test 46. Can anyone outline the procedure of testing these?",
+ "answer": "For EDGE SMTP MT Test 45 and EDGE SMTP MT Test 46 you need to have Disposition-Notification-Options header for the test case to pass. Try the test cases again with the required header.\n EDGE SMTP MT Test 18(a) and EDGE SMTP MT Test 47(a) is a SMTP-SMTP scenario. The system under test (SUT) needs to authenticate with ETT using the credentials vendor1smtpsmtp@ttpds.sitenv.org / vendortesting123. After authentication, a mail needs to be sent to the specified addresses(goodaddress-plain@ttpedge.sitenv.org and noaddressfailure9-plain@dnsops.ttpedge.sitenv.org) to generate the MDN. The MAIL FROM should be vendor1smtpsmtp@ttpds.sitenv.org. \nAfter the above step enter the SUT information (hostname, vendor email address, username, and address) in the profile window.\n Executing the testcase will fetch the MDNs from vendor1smtpsmtp@ttpds.sitenv.org inbox and deliver to the SUT using the information provided in the profile window.\n For EDGE SMTP MT Test 18(a) and EDGE SMTP MT Test 47(a), you need to: \n1. Enter your account information in the 'Profile Panel' on the test page.\n 2. Review the account in the 'More Info' page.\n 3. Connect to the vendor1smtpsmtp@ttpds.sitenv.org account, authenticating with using the credentials shown in more info.\n 4. Send an email to dispatchedonly-plain@ttpedge.sitenv.org and noaddressfailure9-plain@dnsops.ttpedge.sitenv.org from the vendor1smtpsmtp@ttpds.sitenv.org account.\n 5. Wait for a few minutes to allow the MDNs to return.\n 6. Execute the test (RUN), then 'Awaiting Validation', there should be a success notification and the forwarding message.\n 7. Look for negative MDNs in your inbox."
+ },
+ {
+ "question": "We have not been able to successfully send SMTP Messages to wellformed14@ttpds.sitenv.org because we do not have a Trust Anchor and Public Certificate for this domain.\nWe are having the same issue with noaddressfailure9-plain@dnsops.ttpedge.sitenv.org from Test 18.\nWe have already loaded the certificates/trust anchor available here: https://ttpedge.sitenv.org/ttp/#/direct",
+ "answer": "This is the self-signed server certificate that is used by the James server at ttpds.sitenv.org:25. Please add it to your trust store and let us know if this helps. Please note these test cases are Edge protocol plain SMTP-STARTTLS (not Direct)"
+ },
+ {
+ "question": "Where is the certificate for the Apache James server?",
+ "answer": "The certificate for Apache James can be found here:\nhttps://github.com/siteadmin/ett/blob/resources/certificates/common/james/ttpds.sitenv.org.james-tls.cert\nFollow-up: We configured the direct account in Thunderbird and the account which was shown in “More info.” In the direct account settings, choose “default out-going” mail server to direct as ttpds.sitenv.org; which is the SMTP server to the email vendoraccount@ttpds.sitenv.org. Using these settings, the SUT can email to wellformed14@ttpds.sitenv.org via a direct email server, emails are relayed and processing through ttps.sitenv.org. I am able to pass with this approach. The James Certificate is used to encrypt the communication with SMTP/POP/IMAP protocols."
+ },
+ {
+ "question": "SMTP MT Test 46 Certificate Issue: We have installed the Trust Anchor from the TTP site. However, when I attempt to send I got an error as unable to find domain bound certificate for this (wellformed14@ttpds.siten.org) address. Is another way to discover their certificate?",
+ "answer": "This is NOT a direct endpoint. You need to send an SMTP message. If you have you passed SMTP MT 17 and 45, this test should be similar."
+ }
+ ],
+ "XDR": [
+ {
+ "question": "XDR Test 16 says \"Verify that Mutual TLS session is established between the Sender and the Receiver before transmitting data\". I don't fully understand what has to be in place for this test. Do we need to submit a public certificate somewhere in our account that maps to a private key to tell the ETT to trust our system?",
+ "answer": "You have downloaded the direct certificates. These are NOT the certs for mutual TLS. You need to download the certs from the embedded URL above the XDR Test 13 test."
+ },
+ {
+ "question": "The end point I've been testing with is the following: https://vs-... I also just tried running the XDR Validator, and seem to be running into errors there as well.",
+ "answer": "Please ensure you have installed the certificates needed for testing. The Direct certificates can be found on the Direct Home page (https://ttpedge.sitenv.org/ttp/#/direct) and the XDR certificates can be found on the Edge XDR Page, just above the 'Your system as \"Sender\"' button (https://ttpedge.sitenv.org/ttp/#/edge/xdr)."
+ },
+ {
+ "question": "I ran XDR 5 with his endpoint and I see this error in the logs. \nCaused by: { code:\"500\" extendedCode:\"0\" reason:\"XdsInternal error\n SOAP Fault: com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix \"soapenv\" at [row,col {unknown-source}]: [1,158]\" reasonPhrase:\"Internal Server Error\" }",
+ "answer": "expand on the error message, the requirement that the format (Simple SOAP vs MTOM) be the same is specified in IHE ITI Technical Framework, Volume 2, Appendix V: V.8.1 Simple SOAP vs MTOM, \"Both the request and the response messages shall use the same encoding.\"\nMore readable descriptions and the background behind this requirement can be found:\nhttps://wiki.ihe.net/index.php/XDS.b_Implementation#More_on_MTOM_vs_MTOM.2FXOP\nhttps://wiki.ihe.net/index.php/XDS.b_Implementation#Interpreting_Web_Services_Specifications_for_XDS.b_and_XCA\nMost web service packages/libraries (such as Apache Axis2, etc) will make this switch automatically.\n- The timeout for the registry / XDS Toolkit is 60 seconds."
+ },
+ {
+ "question": "What are the XDR, Direct From Address, email endpoints?",
+ "answer": "The endpoints can be found at: https://github.com/siteadmin/ett/wiki/XDR-Endpoints \n The XDR MT Tests use these endpoints for destination:\nMT 13: badaddress@gfail.com\nMT 14: Provider1@direct2.sitenv.org\nMT 15: failure15@ttpds.sitenv.org \n MT 16: nomdn8@ttpedge.sitenv.org\n MT 32: badaddress@gfail.com\n MT 33: Provider1@direct2.sitenv.org\n MT 34: failure15@ttpds.sitenv.org\n MT 35: nomdn8@ttpedge.sitenv.org\n MT 36: processedonly@ttpedge.sitenv.org\n MT 37: processedonly@ttpedge.sitenv.org\n MT 38: processeddispatched6@ttpedge.sitenv.org\n MT 43: processedtimeoutfailure@ttpedge.sitenv.org\n MT 44: processedfailure@ttpedge.sitenv.org"
+ },
+ {
+ "question": "Edge XDR Test 6 (Send): I need to check the integrity, but can't because ETT tool generated HASH is in SHA-1 and is giving a mismatch error. How do I check D* integrity test case along with b1? Is there any link to check this?",
+ "answer": "For this test, all the SUT needs to do is establish an HTTPS connection using the provided certificates. Please download the certificates found at the top of the page."
+ },
+ {
+ "question": "Edge XDR Test 5 (Receive): I am getting Request from ETT tool I validate it and genererate the below response with return type \"String\"\n\nContent-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_45f3cde8-1e8f-4f81-bfdb-c40365cc698a; type=\"application/xop+xml\"; start=\"0.urn:uuid:45f3cde8-1e8f-4f81-bfdb-c40365cc698a@apache.org\"; start-info=\"application/soap+xml\"; action=\"urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse\"...\n\nWant to know how to validate XDR soap header & body ?\nAnd also what should be response format ?",
+ "answer": "Please refer to the IHE specifications and wiki for how to create/validate the XDR messages.\nThere are a few threads in the google group that you can use for reference."
+ },
+ {
+ "question": "Can you confirm that XDR MT Test 50a and XDR MT Test 50b require us to send 1 message with multiple intended recipients? We assume this is the approach vs. 1 message with 1 intended recipient to differentiate it from test XDR MT Test 20a and XDR MT Test 20b (positive and negative MDNs). These tests, XDR MT Test 20a and XDR MT Test 20b, appear to be redundant with regard to tests XDR MT Test 50a and XDR MT Test 50b.",
+ "answer": "The tests, XDR MT 50a and XDR MT Test 50b weren't designed for multiple recipients, each test requires an individual endpoint for testing. The intention of the XDR MT Test 50 a and XDR MT Test 50 b are to demonstrate the rigor of the SUT by sending to several recipients. The Test Procedure directs the SUT to send to one recipient using tests XDR MT Test 20 a and XDR MT Test 20 b, then to multiple recipients using XDR MT Test 50 a and XDR MT Test 50b.\n\nNote: The test script does not direct the SUT to test sending to several recipients at the same time; understanding the confusion, it is asking the SUT to send to multiple valid recipients.\n\n1. Delivery Notification: The user sends XDR messages to multiple valid recipients (XDR MT Test 50a).\n2. Delivery Notification: The user sends XDR messages to multiple invalid recipients (XDR MT Test 50b)."
+ },
+ {
+ "question": "To deliver disposition statuses asynchronously for XDR transmissions, is it expected that first a ResponseStatusType:Success is included by default in the synchronous reply or should it be omitted entirely?",
+ "answer": "Based on the underlying XDR work-flow, ResponseStatusType of Success would be expected to be sent back."
+ },
+ {
+ "question": "To which endpoint should XDR MDN's be sent?",
+ "answer": "The endpoint for each test case should be listed in the UI for each individual test case."
+ },
+ {
+ "question": "What is a sample xml for an XDR MDN that includes both envelope and body?",
+ "answer": "An example of the overall XDR package is available here:\nhttp://wiki.ihe.net/index.php/XDS.b_Implementation#Example_Provide_and_Register_Document_Set-b_transaction\nInstead of sending a document as they have in the example, the message disposition would be sent as defined in section 1.5.2.1.1 of this document (which includes an example):\nhttps://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf"
+ },
+ {
+ "question": "When testing XDR sending, the user must click “RUN” on the tool (to generate the endpoint) and then send a message. When testing SMTP sending, it’s the opposite. The user must send the message and then click “RUN.” This inconsistency makes use of the tool more challenging.",
+ "answer": "This difference in the workflows is an artifact of the underlying technologies and unfortunately not something that would be easy to change on our UI. For XDR, the endpoints must be established ahead of time or else the systems wouldn't know where to send messages. The Direct From address must be known so that the message can be properly routed within the ETT to the correct test instance while the test case is running. The ETT and Toolkit are an active part of this communication. The ETT must be primed BEFORE the communication takes place.\nFor SMTP, the ETT only becomes involved after the mail has been sent and is sitting in a mailbox. The SMTP communication/commands must be completed before ETT can check, or else there is nothing for ETT to find. The ETT can only step in AFTER the SMTP communication akes place.\nThe underlying protocols themselves have different workflows."
+ },
+ {
+ "question": "I have sent my XDR message to the endpoint and receive a Registry Response. However, the ETT never moves past the Pending Refresh button no matter how many times I press it. How do I move forward?",
+ "answer": "Verify that your XDR message contains the Direct Address Block and that Block is completely filled out and matches what was entered into the Test Case UI. The ETT uses the Direct Address block to route the messages; so if the values do not match, they will not be forwarded to the correct module within ETT."
+ },
+ {
+ "question": "I used WCF to implement the XDR recipient web service. When testing XDR Test Case 4a and 4b, the process pipeline created CommunicationException and returned 400 server error to ETT before my codes get control. Here is the message from the ETT log:\nHTTP/1.1 400 Bad Request\nCache-Control: private\nServer: Microsoft-IIS/7.5\nMIME-Version: 1.0\nX-AspNet-Version: 4.0.30319\nX-Powered-By: ASP.NET\nDate: Tue, 11 Oct 2016 16:01:14 GMT\nContent-Length: 0\nMy question is, do we need to return a RegistryResponse with status urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure, or the 400 server error should be enough for this situation?",
+ "answer": "Test case 4a and 4b are negative test cases in the sense that the incoming messages are malformed and must be treated appropriately. The SUT needs to demonstrate that it has detected the abnormality and reacted appropriately (i.e. not accepting the message)."
+ },
+ {
+ "question": "I haven't figured out how to get ETT to show logs from asynchronous replies for the HISP XDR message tracking tests. The fields are: * Endpoint, * Direct From Address, and * Outgoing (ETT --> SUT) Direct From Address",
+ "answer": "Test Case: XDR MT Test 13\nNotes: The specifications detail how an error should be reported back asynchronously, but do not specify when this method should be used; therefore, it is acceptable for a system to send back a registry response failure synchronously or a message delivery failure asynchronously.\nETT Action: The ETT will send a message to the SUT where the final address is non-existent.\nSUT Action: The SUT will respond either synchronously or asynchronously.\nIf it is synchronous, a registry response failure will be sent. If it is asynchronously, a delivery failure message will be delivered.\nProctor Action: The individuals operating the SUT will inform the Proctor how their system responds when a message is asked to be delivered to an address that is non-existent. In the UI, the same logs screen will be used in either the sync or the async case. Depending on whether the communication is sync or async, the Proctor will expect to see a registry response failure in the response tab of the logs (for sync) or a message delivery failure on the request tab of the logs (for async).\nSteps:\n1) Populate the fields. Endpoint parameter refers to the SUT’s listening\nendpoint. Direct From Address refers to the Direct From that the SUT\nwill use if it is sending a response asynchronously. Outgoing Direct\nFrom refers to the Direct From address that the ETT will use for its\ninitial outgoing XDR communication.\n2) Press Run button\n3) The XDR message is sent to the SUT.\n4) If you want to see the synchronous response, press logs or Pending\nRefresh. If you are following the asynchronous option, do not press\nanything on the UI yet. (Synchronous option is finished here.)\n5) The SUT now sends the asynchronous response.\n6) When the asynchronous response is complete, then press Pending Refresh. If the message has been found, this button will turn to Awaiting Validation. Pressing this will bring you to the asynchronous logs."
+ },
+ {
+ "question": "For XDR Test Case 7 why do we not enter a full endpoint?",
+ "answer": "The ETT tracks the incoming messages via the Direct Address block; however, in this case, the SUT is supposed to stop the communication before a message is sent because the certificate is bad. Since, the message should not come through, we will not have access to the Direct Address; therefore, the ETT asks for the IP address and tracks the request through that. Since, this is happening at the socket level, the full path for an endpoint is not applicable."
+ },
+ {
+ "question": "Does anyone know whether it's required to use HTTPS for the sending tests other than 6 &7?",
+ "answer": "HTTPS is required for XDR 6 and 7; however, other XDR tests can be demonstrated using HTTP or HTTPS."
+ },
+ {
+ "question": "Where is the functionality in the ETT for testing the two requirements listed below referenced in the test procedure (https://www.healthit.gov/sites/default/files/170_315h2_Direct_Project_Edge_Protocol_and_XDRXDM_v1_2.pdf)?\n- \"170.315(h)(2)(i)(B) Send Using SOAP + XDR\"\n- \"170.315(h)(2)(i)(B) Receive Using SOAP + XDR\"",
+ "answer": "That functionality is under \"Edge Testing\" from the ETT main menu, then the \"XDR Test Cases\" navbar link at the top of the page."
+ },
+ {
+ "question": "In order to pass XDR Test Case 1, is it necessary to create XDR requests which include the selected document? Where can these samples be found?",
+ "answer": "If you navigate to:\nhttps://ttpedge.sitenv.org/ttp/#/validators, select CCDA R2.1 Validator, then download all files. The samples can be found in the download under: \\CDAs\\2015-Certification-C-CDA-Test-Data-master\\Receiver SUT Test Data. Alternatively, the file is also at: https://github.com/siteadmin/2015-Certification-C-CDA-Test-Data/tree/master"
+ },
+ {
+ "question": "Specific tests require the SUT to receive an XDR message, translate it, then send back to the ETT via Direct. The sender address of the outgoing Direct message is supposed to match up with the address that we pre-registered, but the direct:to and direct:from fields in the received XDR message both contain the address testc...@edge.nist.gov. So, my understanding is that we must implement a workaround to change the sender address on the outgoing side. Is that correct?",
+ "answer": "Functionality is being added to make the direct from information configurable from the UI in the HISP XDR test cases. The tests were updated to include a \"From\" address entry box."
+ },
+ {
+ "question": "Unlike the other edge reliable messaging tests there is no place to configure the callback URL for the message dispositions. Is the test expecting to find a HISP with the associated endpoint or is the intent to verify that the direct:addressBlock contains the X-DIRECT-FINAL-DESTINATION-DELIVERY element?",
+ "answer": "XDR MT test 48 is testing only the SUT's ability to generate three messages with unique IDs. The message dispositions are out-of-scope for this test. Once the three unique message IDs are found (or found not to be unique) the test is complete."
+ },
+ {
+ "question": "What are the differences between tests XDR MT Test 19 and XDR MT Test 48?",
+ "answer": "You run MT 19 if you're implementing Message Tracking Using Processed MDN. You run MT 48 if you're implementing Message Tracking Using \"Implementation Guide for Delivery Notification\"."
+ },
+ {
+ "question": "We have downloaded the keystore from the above site and configured our tomcat server to use it for secure connection; however, no secure connection can be established. We performed the tests this afternoon, around 1:30pm Central. Our endpoints are as follows:\n\nNon-secure: http://ych-qa-mu3.test.yourcareuniverse.net:9280/connex-ett/xdsb/pushDocumentSet\n\nSecure: https://ych-qa-mu3.test.yourcareuniverse.net:9283/connex-ett/xdsb/pushDocumentSet\n\nPlease advise us of how to resolve this issue.",
+ "answer": "We found the logs for this test case :\n\nINFO 3888 --- [io-12080-exec-1] g.n.h.ttt.xdr.api.TLSClientImpl : Sending a request to the server using socket:\nSocket class: class sun.security.ssl.SSLSocketImpl\nRemote address = ych-qa-mu3.test.yourcareuniverse.net/52.73.115.17\nRemote port = 9283\nLocal socket address = /172.31.38.171:36196\nLocal address = /172.31.38.171\nLocal port = 36196\nNeed client authentication = false\nCipher suite = SSL_NULL_WITH_NULL_NULL\nProtocol = NONE\njavax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHands\nhakeException: Received fatal alert: bad_certificate\n\nIt looks like you are using a bad certificate. Please re-download the certificate and re-install it."
+ },
+ {
+ "question": "XDR Test 3 (Revieve): We believe we having an issue Receiving the Documents and saving to the EHR. We have code to check for a document ID which has been sent in the past. Is there a way we could set the unique document ID in the test so that we can import the files more easily?",
+ "answer": "The ETT uses a symbolic ID (\"Document01\") in the metadata to identify the attached document:\n\nIt is incumbent upon the receiving registry in a provide and register transaction to turn the symbolic ID into a UUID of their choosing. In IHE ITI, Volume 2b, see Section 3.42.4.1.3.7 UUIDs and Symbolic Ids:\n\"If a field is formatted as a symbolic Id in the Submission Request, the Document Registry shall replace it with newly generated, properly formatted UUIDs upon acceptance of the submission. If the same symbolic Id appears more than once in the Submission Request, it shall be replaced with the same generated UUID.\"\nThe receiving system must be able to handle symbolic IDs in accordance with the base IHE specifications."
+ },
+ {
+ "question": "What are the differences between tests XDR MT Test 19 and XDR MT Test 48.",
+ "answer": "XDR MT Test 19 is for Message Tracking Using Processed MDN. XDR MT Test 48 is for Message Tracking Using \"Implementation Guide for Delivery Notification\"."
+ },
+ {
+ "question": "ETT is not succeeding for us on XDR Test 8, though we seem to be able to perform mutual SSL with the provided client certificate using OpenSSL. XDR Test 8 is not giving us much information about why it is failing. I suspect ETT is not trusting our server certificate. We have had issues before with certain systems not including GoDaddy's intermediate certificate authority, resulting in an incomplete certificate chain.",
+ "answer": "The certificate provided for the XDR transactions needs to be used in both sides of the mutual TLS connection (it's loaded into our keystore and your keystore or equivalent). We don't look for your server certificate, the toolkit is already loaded with the provided, self-signed cert."
+ },
+ {
+ "question": "In the XDR test 8 for mutual TLS, the following test step is used:\n“Verifies the ability of the receiving system to complete a mutual TLS handshake before data is sent across. Certificates for this test can be downloaded from the link at the top of this page. As this is a socket-level test, the full endpoint is not necessary and only hostname and port are to be entered below”.\nWhere can the referenced certs be downloaded from?",
+ "answer": "There is a download link above the “Your System as: Sender” with light blue text, “Click to download TLS Certificates”. "
+ },
+ {
+ "question": "XDR MT Test 30 includes a Direct To Address field, which is only used for async responses in other tests. However, my understanding is that this test is only checking that the SUT can handle the X-DIRECT-FINAL-DESTINATION-DELIVERY header, not that the resulting delivery notification is valid. Am I correct? If so, what is the purpose of the Direct To Address field?",
+ "answer": "The X-DIRECT-FINAL-DESTINATION-DELIVERY header is what is checked for this test case.\nThe “DIRECT To:” is the direct address that is responded to and is registered/mapped in the Direct portion of the ETT.\nThe \"Outgoing (ETT --> SUT) Direct From Address\" refers to the value that we place in the element in all outgoing messages from ETT to the SUT. This may be optional for your system."
+ },
+ {
+ "question": "Is there a sample you can provided for XDR MT TEST 30 so show what the header should look like?",
+ "answer": "The soap body could itself be inspected from the \"Log\" section of the test by clicking the \"Waiting for Validation\" or \"Logs\" button after running the test.. Please let us know if this is not what you are looking for.\n\nOf particular interest is this part true\ntrue\nFollow-up: In the 30 and 31, the proctor needs to verify that the headers are being processed and \"accept\" / \"reject\" based on the demonstration.\n\nFor 32 and above, the \"Logs\" button can be used to see the synchronous/asynchronous delivery notification produced by the System Under Test (SUT), however, the process of accept/reject still remains the same - a verification by the proctor as per IG for Delivery Notification 1.5.2.1.1.\n\n\"The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite\""
+ },
+ {
+ "question": "Please confirm my understanding. The ETT for XDR MT TEST 30 sends a a VALID delivery notifications request to the system under test in the following format. The system under test then sends a Direct message based on the VALID delivery notifications request. If I am correct then is the format above that you sent me the complete VALID delivery notifications request? We are trying to give vendors a sample of what the VALID delivery notifications request looks like.",
+ "answer": "Yes, that is correct; the format is same - however the multi-part identifier and other ids and direct:from/to elements will differ based on the session."
+ },
+ {
+ "question": "The vendor does not understand XDR MT TEST 30, and I am not 100% sure of what role the Test Proctor has in the verification process. This is the message flow chart from page 11 of the IG for Delivery Notification. So...\n1. The ETT acts as the Receiving STA because the ETT sends a VALID delivery notifications request?\n2. The SUT is expected to receive this valid delivery notification, and send a success notification back to the ETT (with the ETT acting as the original sending Edge client?\nIf this is correct then what format of the success notification is the ETT looking for? And, what verification does the proctor do since it seems that some verification is done automatically by the ETT, and other verification seems like it is visual inspection by the proctor.",
+ "answer": "The complete positive delivery notification flow described is being tested in XDR MT TEST 38 (and in these cases, ETT only shows the logs and no automatic verification is being done, the proctor has to accept/reject based on visual inspection as per examples in the IG for Direct-Edge 1.5.2.1.1.)\nHowever, XDR MT TEST 30 tests only a part of it, namely that the XDR well formed header is being processed by SUT - this can be demonstrated by showing the SUT logs. Similarly XDR MT TEST 31 can be demonstrated by the SUT log message of an error in the malformed field. Technically speaking XDR MT TEST 38 subsumes XDR MT TEST 30.\nFor XDR MT TEST 38, you are right - ETT acts as a sending Edge by requesting the Delivery Notification through the header. And SUT is expected to receive this valid notification and send it back to the ETT (acting as the Edge XDR) - which can be viewed from the tool's log button - in this case, the example of the notifications are given in the document example from IG for Direct-Edge 1.5.2.1.1.\n \nmailto:entity1@direct.example.org\nsuccess\n\n(for negative cases, XDR MT TESTs 33-37, this would correspond to failure with an optional reason for failure as per the example)"
+ },
+ {
+ "question": "The SUT is never creating a notification in MT 38 since it just forwards a copy of the notification from the ETT back to the ETT?\n\n\"For XDR MT TEST 38, you are right - ETT acts as a sending Edge by requesting the Delivery Notification through the header. And SUT is expected to receive this valid notification and send it back to the ETT (acting as the Edge XDR)\"",
+ "answer": "SUT is copying the notification from ETT received through Direct SMTP back to ETT - but now using XDR (Edge)."
+ },
+ {
+ "question": "Where is the XDR SAML validation in the ETT?",
+ "answer": "It is available in the XDR Validator in the Message Validators section:\n\nhttps://ttpedge.sitenv.org/ttp/#/validators/xdr\n\nThe receive part validates the incoming SAML and the send part has the ability to include the headers in the outgoing message."
+ },
+ {
+ "question": "The HTTPS XDR test endpoints aren't working properly, specifically XDR Tests 3 & 5.",
+ "answer": "Please ensure you have downloaded the certificates and installed them. The certificates can be found at the top of each test section, beneath the ribbon bar and above the button \"Your System as: Sender\". Look for, \"Click to download XDR TLS certificates\".\n\n- Here are some examples for XDR:\nhttp://wiki.ihe.net/index.php/XDS.b_Implementation#Example_Provide_and_Register_Document_Set-b_transaction_.28with_full_metadata.29\n\nftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/XDS.b/\n(Provide and register examples)"
+ }
+ ],
+ "XDM": [
+ {
+ "question": "My XDM is not being validated because the tooling says it cannot find the metadata, or cannot open the zip, or is not moving forward in the validation steps.",
+ "answer": "Check that the IHE_XDM and SUBSET01 directories have been explicitly created. When the ZIP file is viewed, there should be a specific entry for each directory listing.\n\n- Some examples for XDM:\nftp://ftp.ihe.net/Connectathon/samples/XDM_samples/\n\nA table showing the difference in optionality between the different XD* metadata is available in Vol 3 of IHE ITI:\nhttp://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf See table \" 4.3.1-3: Sending Actor Metadata Attribute Optionality\" starting on page 109."
+ },
+ {
+ "question": "I have tried to validate some XDM zip's, but it seems that the validator stops at point 'Decoding ZIP'.\nIt works with the sample found on ftp://ftp.ihe.net/Connectathon/samples/ITI-profiles/XDM_samples/ but if you try to decompress and compress it again, it does not work anymore.\n\nI've tried with different compressing algorithm like 'Deflate', 'Deflate64', 'LZMA', 'PPMd', 'BZIP2', but none of them works. If you try with those kind of algorithm, you will see java exceptions of the validator saying 'not supported algorithm...'\nSo my question now is how to compress files to create a valid XDM-Zip?",
+ "answer": "Tested working solutions are:\n\n* Using of 7-Zip (17.00 beta) -> But you have to set the 'relative path' again in the GUI.\n* Using of MacOS X line command, navigate to the folder that contains all XDM-files and use 'zip -r *'\n* Using WinRAR 5.40 (64bit) -> make shure that value 'Store relativ path' under tab 'Files' is selected\nThe IHE specification states to use the ZIP format, not the RAR format for compression."
+ }
+ ],
+ "C-CDA": [
+ {
+ "question": "How do you use the C-CDA 2.1 Validator?",
+ "answer": "1. Using the C-CDA Validator 2.1, Step 1 is to select whether you are performing a Sender specific test or Receiver Specific test (Select Sender / Receiver).\na. The above choice will make what appears when you click the “Select Document “ to change based on the SUT role.\nb. In your case you would select “Sender”\n2. Then you would select the criteria first and for each criteria that you select you may have one or more PDF files.\n3. You would download the PDF file,\n4. Enter the test data provided into your SUT instance.\n5. Generate a C-CDA document. (This is C-CDA Validator Step 2)\n6. Then in the C-CDA Validator Step 3, you have to select the Criteria and the PDF file which you used to generate the C-CDA.\n7. Then upload the C-CDA file that you generated in C-CDA Validator Step 4 and then validate.\n\nThe above sequence is what you would use to validate the C-CDA files you generated using the test data.\n\nIf you want to validate files generated by your system without using the test data provided then you can proceed to Step 3 and select “CCDA_IG_Only” or “CCDA_IG_Plus_Vocab” options and then upload and validate. This is to help vendors prepare their systems however certification procedures require the use of the provided test data unless you work with the ATLs to file for deviations to the test data."
+ },
+ {
+ "question": "Can multiple organizations be included as information recipients within the element?",
+ "answer": "CDA allows for 0..* information Recipients. You should include more than one informationRecipient if you’d like to send information to multiple organizations."
+ },
+ {
+ "question": "How can CCDA xml files for interoperability modules be created to include multiple races and ethnicities?",
+ "answer": "There is an extension package that may be used.\nsdtc:raceCode\nsdtc:ethnicGroupCode\nSee the C-CDA companion guide for additional details:\nhttp://www.hl7.org/implement/standards/product_brief.cfm?product_id=447"
+ },
+ {
+ "question": "I'm now trying to increase the debugging output from the validator, hopefully to see where my issues exist with the vocabulary. I've tried using a global DEBUG level in the logging.properties file and setting to ALL, but it appears that the validator doesn't look at the properties file to set it's level of logging.\n\nDoes anyone know where I can change that info level for the validator classes?\n\nThe logging that I do get appears to show the vocab/valuesystems loading just too quickly.\n\n08:27:14,748 INFO [VocabularyLoadRunner:92] Loading vocabularies at: /var/tomcat2/ValidatorConfig/CodeSystems...\n08:27:14,748 INFO [VocabularyLoadRunner:94] Vocabularies loaded...\n08:27:14,748 INFO [VocabularyLoadRunner:99] Loading value sets at: /var/tomcat2/ValidatorConfig/ValueSets...\n08:27:14,749 INFO [VocabularyLoadRunner:101] Value Sets loaded...\n08:27:14,749 INFO [VocabularyLoadRunner:105] !!!!*********** VOCABULARY DATABASE HAS FINISHED LOADING - SERVER WILL CONTINUE AND SHOULD BE DONE SHORTLY. ***********!!!!",
+ "answer": "15:02:46,635 INFO [VocabularyLoadRunner:92] Loading vocabularies at: C:\\CCDA\\Validator\\code_repository...\n15:02:46,636 INFO [VocabularyLoadRunner:44] Loading files in : CDT...\n15:02:47,758 INFO [VocabularyLoadRunner:44] Loading files in : ICD10CM...\n15:02:51,412 INFO [VocabularyLoadRunner:44] Loading files in : ICD10PCS...\n15:02:53,378 INFO [VocabularyLoadRunner:44] Loading files in : ICD9CM_DX...\n....\nC:\\CCDA\\Validator\\valueset_repository...\n15:04:37,554 INFO [VocabularyLoadRunner:44] Loading files in : VSAC...\n15:04:37,555 INFO [VsacLoader:30] Loading Value Set File: Ability.xlsx\n15:04:37,662 INFO [VsacLoader:30] Loading Value Set File: ActPriority.xlsx\n15:04:37,708 INFO [VsacLoader:30] Loading Value Set File: ActStatus.xlsx\n...\n\nHere are my config settings for the the codes set and value set files:\n \n\nThe localCodeRepositoryDir is the path to the folders (e.g. ICD9CM_DX, ICD9CM_SG, ICD10CM, etc...) that contain the code set files.\nThe localValueSetRepositoryDir is the path to the VSAC folder that contains all of the value set files.\nI believe the application is hard-coded to look for those particular folders in order to process the files within. That may be case-sensitive..."
+ },
+ {
+ "question": "Hello, were there any updates made to the tool? I'm getting this same error with problem codes for \"no known problems\".",
+ "answer": "No specific updates were made to the tool to remove the validation for the “No Known Problems”.\nAre you following the HL7 example at http://hl7-c-cda-examples.herokuapp.com/examples/view/7353a215efda8dfe3fbacb19abbb90756ce14bab"
+ },
+ {
+ "question": "Hoping to obtain some clarity around representing NDC codes for administered immunizations in the C-CDA.\n\nNDC is published as a standard for immunizations as a CCDS element and the ONC's CCDS companion guide cites that it's supported as a translational element accompanying the CVX code in CDA R2.1. Looking at the 2.1 IG, NDC is referenced within the Immunization Medication Information entry-level template with the Vaccine Clinical Drug value set stating: \"Value set intensionally defined from RXNORM (OID: 2.16.840.1.113883.6.88), comprised of those codes whose ingredients map to NDC codes that the CDC associates with CVX codes.\" Reading this and viewing the provided examples it appears as though the IG expects only RxNorm codes (not NDC) to be used as translational element entries mapping between an NDC and a CVX.\n\nNDC's are not actually included anywhere in the certification test data/validation for immunizations (only CVX), and I'm struggling to find any examples of their use for immunizations in C-CDA. Is there a specific expectation of how NDC codes are to be represented in C-CDA docs (if at all) to satisfy the ONC's CCDS standard?",
+ "answer": "The test data contains CVX because that is accompanied with a SHALL requirement in the C-CDA IG.\nSince the translation elements are having a conformance statement of “MAY” and not a “SHALL”, you could choose to use the NDC codes mapped to the CVX codes in the translation element as specified by the CCG."
+ }
+ ],
+ "Other": [
+ {
+ "question": "In our implementation and definition of our Edge system and our HISP, we are not able to use the ETT as our HISP to connect to our Edge system. (This reference from the Federal Register's published Final Rule supports our implementation: https://www.federalregister.gov/d/2015-25597/p-1114. Relevant text in the screenshot below).\n\nFor XDR Test 5, the ETT \"More Info\" link says:\n\nDescription:\nVerify that an Edge system can receive a properly formatted XDR message. The SUT will receive the XDR message with a 'direct:from' and 'direct:to' address of testcase5@ttpedge.sitenv.org. This was designed to require the SUT's endpoint as the only input parameter.\n\nExpected Result:\nEdge system is capable of receiving and processing a valid message with Full Metadata, test procedure may include other details for verification. Test Tool is satisfied with a good response.\n\nBecause that is not a domain that we manage, our system is rejecting the XDR messages. To resolve this issue, we have mapped inbound XDR messages with a To address domain of @ttpedge.sitenv.org to a domain that we manage in order to successfully receive these messages. We have been able to successfully complete these tests.",
+ "answer": "The demonstration of a successful receipt of the message is the benchmark. The domain mapping approach you describe is acceptable."
+ },
+ {
+ "question": "Is it safe to send Protected Health Information (PHI) to NIST tooling?",
+ "answer": "No! Never send Protected Health Information (PHI) to the ETT server. If necessary, local copies of our tooling can be downloaded and installed. DO NOT send live data to the tool on our website, there is no protection for PHI/PII."
+ },
+ {
+ "question": "How do we differentiate between a PRN medication and a Daily once frequency medication?",
+ "answer": "Right now, the presence of a 'precondition' with appropriate nullFlavor is an indicator for PRN without a precondition. If you have a precondition, that that is your precondition PRN - if this is a problem in your current live implementation, please come to HL7 SDWG (Thursday 10-12 PM ET - Agenda) - happy to discuss alternative approaches. \" QD = daily\" & \"PRN = As needed\"; You can have 'Daily with a specific precondition (e.g. Back pan) or 'Daily as-needed'\n(aka QD PRN). If you want to present an example with precondition, we are happy to have\nyou on the HL7 examples task force."
+ },
+ {
+ "question": "We're having an issue Receiving the Documents and saving to the EHR. We have code to check for a document ID which has been sent in the past. Is there a way we could set the unique document ID in the test so that we can import the files more easily?",
+ "answer": "The ETT uses a symbolic ID (\"Document01\") in the metadata to identify the attached document:\nIt is incumbent upon the receiving registry in a provide and register transaction to turn the symbolic ID into a UUID of their choosing. In IHE ITI, Volume 2b, see Section 3.42.4.1.3.7 UUIDs and Symbolic Ids: \"If a field is formatted as a symbolic Id in the Submission Request, the Document Registry shall replace it with newly generated, properly formatted UUIDs upon acceptance of the submission. If the same symbolic ID appears more than once in the Submission Request, it shall be replaced with the same generated UUID.\" The receiving system must be able to handle symbolic IDs in accordance with the base IHE specifications."
+ },
+ {
+ "question": "We're getting an error message while trying to validate a C-CDA file- any suggestions?",
+ "answer": "All prescribable medication formulations are represented using either a \"generic\" or \"brand-specific\" concept. This includes RxNorm codes whose Term Type is SCD (semantic clinical drug), SBD (semantic brand drug), GPCK (generic pack), BPCK (brand pack), SCDG (semantic clinical drug group), SBDG (semantic brand drug group), SCDF (semantic clinical drug form), or SBDF (semantic brand drug form). It does not include the PSN term type, hence the error. If PSN needs to be included, it should be an ERRATA through HL7."
+ },
+ {
+ "question": "For Negative Testing CCDS samples 2 and 3, there is a SNOMED code \"27171005\" which is being validated in the ETT Message Validator as a LOINC code and throwing an error. It appears that this is a valid SNOMED code in the results section of a procedure. Will the ETT Message Validator be updated to address this issue?",
+ "answer": "Negative Testing which is being performed as part of the b1 capability is to ensure that the System Under Test (SUT) is more robust and is able to receive and parse C-CDA’s more effectively including the CCDS data elements. All of the CCDS vocabulary requirements that are enforced for normal b1 sample XML files are valid for negative testing also."
+ },
+ {
+ "question": "I tried to understand the certification criteria but got stuck with understanding 170.315(h)(1) & (h)(2). I don't understand why h1, looks like h2 is covering h1. I have couple of questions:\n1. What is a edge system how to implement it? DO I HAVE TO for this MU3 Certification?\n2. As of my knowledge, a HISP can be implemented by using Direct project JAVA RI, but I don't understand what an edge protocol is and how to implement?\n3. All documents in the \"Implementation Guide for Delivery Notification in Direct V 1.1\" and the \"Applicability Statement for Secure Health Transport V 1.2\" are talking about HISP-SMTP, Edge-SMTP, and SOAP protocol what is the deference?",
+ "answer": "The definition of an Edge system and Edge protocols are defined in Implementation Guide for Direct Edge Protocols Version 1.1 which is available here:\nhttps://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf. \n Questions regarding the Certification Program should be addressed via email to: ONC.Certification@hhs.gov. You will also discover information at this link: https://www.healthit.gov/policy-researchers-implementers/2015-edition-test-method"
+ },
+ {
+ "question": "Attached is an Edge sample file with UNKNOWN for patient race and ethnicity. I have tried but could not find UNKNOWN any where in OMB/CDC race and ethnicity value set codes. I have tried several ways, but it is giving data validation error. Please guide us from where i can find code for UNKNOWN race and ethnicity. Is there issue in sample file data ??",
+ "answer": "Please refer to the C-CDA IG for the appropriate value sets and the codes for Unknown."
+ },
+ {
+ "question": "What is the process for configuring a SUT for Mutual TLS Authentication? I understand that the SUT can download the cert from the ETT for it to trust the tool. How does the ETT trust the SUT?",
+ "answer": "That same cert will need to be loaded into the SUT as well. The same cert is used for both sides of the mutual TLS connection."
+ },
+ {
+ "question": "Do HTTPS end points work, it isn’t working for us.",
+ "answer": "Vendors need to be aware of the following when using HTTPS endpoints.\n1. SUT has to import the ETT published certificates to use for Mutual TLS.\n2. They need to provide these certs in the Mutual TLS handshake when using HTTPS.\n3. Sometimes when using the ETT certs, vendors encounter exceptions.\na. Here is an example:\ni. When attempting to run tests in the Edge Test Tool, we added the Certificates into our system. We noticed a critical failure and were unable to send a message due to an issue we found with the cert.pem file. There is a Core Java feature that requires the contents of the subject (CN) to match the host. What we expected was CN=ttedge.sitenv.org but what we saw was CN=test.\nTo fix the above problem identified in bullet #3, the vendor can use the approaches outlined below.\na. If there are issues with the CN name, it is possible to map the host file (1).\nb. Alternatively make a change programmatically per the IHE recommendation (2).\nIt is acceptable to use the hostname implementation approach or the approach identified by the IHE. Using the approach identified in the IHE wiki will allow you to interoperate with other Endpoints who follow the IHE spec and provide certificates which don’t have the right CN value.\nIf you did it programmatically, you set the address as the requirement; however, the host name approach is also fine as long as you know that in the real world might encounter the same issue and you will have add more host names.\n(1) Please see the post below for the host file mapping solution.\n“What we expected was CN=ttedge.sitenv.org but what we saw was CN=test.\nTo resolve this issue, we added a entry into our host file to map \"test\" to \"ttpedge.sitenv.org.\" Please confirm this approach is acceptable.”\nhttps://groups.google.com/d/msgid/edge-test-tool/1f1c6fdd-834e-44d9-856d-57d4a07ed391%40googlegroups.com. \n Please see the posts below for the IHE programming solution. How do I eliminate exceptions caused by Certificate mismatches with the server host name? The ATNA profile says nothing about whether the DNS name of the host must match the name specified in the certificate. It assumes that possession of the certificate with the private key is sufficient to protect the connection. By default, the Java HttpsURLConnection verifies the DNS name of the host against that of the certificate. If you want to disable this, the easiest way is to add the following lines of code somewhere in the initialization of your application. HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() { public boolean verify(String hostname, SSLSession session) { return true; } }); Alternatively, you can call setHostnameVerifier on your URLConnection. connection.setHostnameVerifier(new HostnameVerifier() { public boolean verify(String hostname, SSLSession session) { return true; } }); http://wiki.ihe.net/index.php/ATNA_FAQ#How_do_I_eliminate_exceptions_caused_by_Certificate_mismatches_with_the_server_host_name.3F https://groups.google.com/d/msgid/edge-test-tool/068f7a3c-365b-4a30-bc86-d1a6eb794590%40googlegroups.com."
+ },
+ {
+ "question": "Does ETT has added the following accredited trust bundle into the testing system?",
+ "answer": "The public certificate and trust anchors used by TTP/ETT are available here: https://ttpedge.sitenv.org/ttp/#/direct"
+ },
+ {
+ "question": "From what I understood from the documentation, for successful execution of the test procedures for 170.315(h)(1), the direct mail server does not require STARTTLS. Can your ensure that my understanding is correct?",
+ "answer": "Yes, the Direct transport does not make use of STARTTLS; while, the mail-based Edge protocols do use STARTTLS."
+ },
+ {
+ "question": "Where can ATLs download the latest release of the ETT for local installation? Today (September 28th) the NIST hosted tool (https://ttpedge.sitenv.org/ttp/#/home) and the release notes (https://ttpedge.sitenv.org/ttp/#/edge/releaseNotes) report the current version is 1.1.0. The latest version of the JAR file found at the Bit Bucket downloads link is ett.1.0.19.jar (https://bitbucket.org/jperugini/ett/downloads?tab=downloads), which has a release date of June 24th, 3 months prior to the date of the current release.",
+ "answer": "The current release packages are available here: https://github.com/siteadmin/ett/releases"
+ },
+ {
+ "question": "Does the ETT require the same unique message ID when the message is sent to multiple recipients, or is it acceptable to have different message IDs for each recipient?",
+ "answer": "Message IDs must be unique."
+ }
+ ]
+}
diff --git a/src/components/resources/data/faq.md b/src/components/resources/data/faq.md
new file mode 100644
index 00000000..a1b9ad61
--- /dev/null
+++ b/src/components/resources/data/faq.md
@@ -0,0 +1,754 @@
+# Frequently Asked Questions
+
+## Direct
+
+- Q: We are trying to use the "Send a Direct Message" from the Edge Testing Tool to our implementation and are showing a "time-out" status in the Message Status portal.
+
+ - A: Please unsure that you have installed the Trust Anchor for the ETT into your system.
+
+- Q: We are testing the "Send a Direct Message" functionality as part of our H1 testing:
+ https://ttpedge.sitenv.org/ttp/#/direct/send
+ But are having an issue with the SHA-256 option. Can you confirm the SHA-256 option is sending the correct hash? It appears to be sending the SHA-1 hash in the message.
+
+ * A: The first is the hash used to sign the Direct message. The second is the hash that is used in the XD* metadata and refers only to the hash of the attachment itself. These are two separate hashes, calculated independently.
+
+The first hash is defined in the Direct Applicability Statement.
+Version 1.0 mentions both SHA-1 and SHA-256 which is why the Direct portion of the ETT tooling allows both to be used for testing.
+
+The second hash (which is the one from the SOAP body below) is part of the XD\* metadata. The definition of the hash slot is in IHE ITI TF Vol 3 Table 4.2.3.2-1 (page 64)
+.
+The data type for this hash is "SHA1" only.
+
+The document metadata is separate from the signing of the Direct message.
+
+- Q: Why am I not receiving a validation report?
+
+ - A: Please verify that you have registered your direct address with a corresponding contact address which is where the validation report will be delivered, see https://ttpedge.sitenv.org/ttp/#/direct/register. If you have registered, please check the spam folder to see if the validation report has been held there. Also, the local mailbox (the part before the '@' symbol) portion is case-sensitive;verify that the case in what was registered matches what is being sent.
+
+- Q: Why can't the ETT find my certificate via LDAP?
+
+ - A: Please make sure that the LDAP server and port are accessible and not blocked by a firewall. We have been told of issues with older library packages (such as ApacheDS) that were resolved when the library packages were upgraded.
+
+- Q: The proctor sheet states: “using the health module functionality, the user sends an encrypted and signed direct “wrapped” message payload to the ETT Direct to email address.” Where is the ETT Direct to email address?
+
+ - A: Use: https://ttpedge.sitenv.org/ttp/#/direct
+ - If you are using CCDA R1.1, the scope and direct addresses are in the lower section of the page. Clicking the widget on the right side, for the corresponding address, will copy it to your clipboard.
+ - If you are using CCDA R2.1, the direct address will be generated when you select the document you
+ are conforming to. Use the button to select the document and the direct to address will appear underneath it.
+
+- Q: What is the difference between these two validator sides?:
+
+ 1. This one is for certification:
+ https://ttpedge.sitenv.org/ttp/#/validators
+
+ 2. Another that some people have used:
+ https://sitenv.org/sandbox-ccda/ccda-validator
+
+ - A: The backend is the same; it’s simply a different interface.
+
+- Q: In the Direct section of the ETT, sending a direct message to the system under test results in a validation result for the MDNs the SUT produces. I don't believe this case should be sending validation results at all since the testing is around the certificates rather than the MDNs. It looks like the MDNs are being validated as direct messages whether or not the MDN is wrapped. The ETT also seems to be fine with the MDNs in test cases 39, 40 and 41. Should we be receiving validation results for our MDNs in this case?
+
+ - A: The Direct section of the tool always returns validation reports because it has no programmatic way of knowing what the endpoint is being used for. If the test you are running doesn't need a validation report, the validation
+ report can be ignored. The tool accepts wrapped or unwrapped because of backward compatibility with
+ the previous round of certification where wrapped was optional. Information on whether the message was wrapped or unwrapped is contained in the validation report. Edge test cases won't produce separate validation reports.
+
+- Q: I'm not getting validation emails from the Direct Testing part of the ETT.
+
+ - A: The address registered, needs to have a contact email address associated with it.
+
+- Q: SMTP MT Test 39, 40 and 41 are not working. All have been working for us previously. After clicking "Run", I see no attempt at an inbound SMTP connection to my server. I have tried using both a hostname and an IP address.
+
+ - A: Please upload your trust anchor/public cert using the "Upload Certificate" on the left bottom corner of the "More Info" section for the these tests.
+
+- Q: I have imported the invalid trust anchor in DIRECT Server & removed the valid Trust anchor of the ETT. I'm sending an email from the ETT, selecting "GOOD_CERT" what is the expected functionality. My DIRECT Server is not rejecting this message, though I have an invalid trust anchor in my DIRECT Server.
+
+ - A: The certificate that you are selecting is the “Signing Certificate”. So a GOOD CERT will send a message with a signing certificate that is valid. The trust anchor, that you have, should dictate whether messages from a particular address is accepted or rejected. If you don’t have the right trust anchor, then the message should be rejected. That is the expected behavior.
+
+- Q: Not sure what I'm missing. I've uploaded the trust cert and the log shows a message sent to the proper address
+
+1: SENDING EMAIL WITH MESSAGE DISPOSITION NOTIFICATION HEADER TO sand...@direct....
+2: Email sent Successfully
+3: Message-ID of the email sent
+
+However nothing is hitting our SMTP server. I was able to get messages from the DCDT tests as well as
+Send Direct Message tests. Am I missing a setup somewhere?
+
+ * A: Ensure you have uploaded your cert/trust anchor in the left sidebar under profile, here.
+ (https://ttpedge.sitenv.org/ttp/#/hisp/mu2)
+
+We see this in the logs:
+WARN 11:03:15,208 | org.nhindirect.stagent.trust.TrustModel | enforce(OutgoingMessage message) -
+could not trust any certificates for recipient H.......@....com
+
+- Q: What are the SMTP MT addresses?
+
+ - A: The addresses are listed below. Also consult with your ALT for any changes or updates.
+ - SMTP MT Test 21: processeddispatched6@ttpedge.sitenv.org
+ - SMTP MT Test 23: badaddresst@ttpds2.siten.org
+ - SMTPMT Test 24: provider1@direct2.sitenv.org
+ - SMTP MT Test 25: failure15@ttpds.sitenv.org
+ - SMTP MT Test 26: nomdn8@ttpedge.sitenv.org
+ - SMTP MT Test 27: processedonly5@ttpedge.sitenv.org
+ - SMTP MT Test 29: processeddispatched6@ttpedge.sitenv.org
+
+## Direct Edge -- SMTP/POP/IMAP
+
+- Q: We are having issues running SMTP Test 8, 14, 18 (Send) and SMTP MT Test 46, the credentials don't work.
+
+ - A: Please look at the information in the 'More Info' pages for the credentials required to run these tests.
+
+* SMTP Test 8, 14, 18 (Send): wellformed1@ttpedge.sitenv.org, vendoraccount@ttpds.sitenv.org / vendortesting123
+* SMTP MT Test 46: wellformed14@ttpds.sitenv.org, vendoraccount@ttpds.sitenv.org / vendortesting123
+
+- Q: We are testing SMTP Test 8, 14 (Send), per the test in the ETT and following the user guide and it keeps failing. Do we need to install a certificate for this test? We also checked our Direct server and it works with the other Direct protocol tests.
+
+ - A: This is a SMTP protocol test, not a DIRECT test. If you send using Direct to an SMTP endpoint, it will always fail. A Direct message employs an encryption standard using the certificates published in DNS/LDAP built on the top of SMTP to allow the secure exchange of messages; whereas, plain SMTP does not.
+
+- Q: The Edge test case SMTP 18 states, the SUT needs to connect to the ETT SMTP server using the credentials vendor...@ttpds.sitenv.org / vendortesting123 and send an email to wellf...@ttpedge.sitenv.org".
+
+Is the ETT SMTP server ttpds.siteenv.org?
+
+ * A: Yes, ttpds.sitenv.org is the SMTP ETT server.
+
+- Q: SMTP MT Test 1 (Message to Bad Address); I am responding with a DSN rather than an MDN. I am using SMTP for both sending and receiving. I am not using IMAP or POP at this time. Is that acceptable? If not, why not?
+
+ - A: For these cases, ETT acts as the EDGE SMTP sender (and also the notification SMTP receiver) - and so, the ETT is set up to check for the MDNs in the failure15@ttpds.sitenv.org inbox. The SMTP/SMTP cases are designed such that ETT as an Edge SMTP server sends through the HISP, and expects the HISP to deliver the mail to its inbox failure15@hisp-testing2.nist.gov.
+
+- Q: I entered my profile information, went to message tracking and followed the instructions for each of the testcases. These test cases are failing: EDGE SMTP MT Test 18(a), EDGE SMTP MT Test 47(a), EDGE SMTP MT Test 45 and EDGE SMTP MT Test 46. Can anyone outline the procedure of testing these?
+
+ * A: For EDGE SMTP MT Test 45 and EDGE SMTP MT Test 46 you need to have Disposition-Notification-Options header for the test case to pass. Try the test cases again with the required header.
+
+ EDGE SMTP MT Test 18(a) and EDGE SMTP MT Test 47(a) is a SMTP-SMTP scenario. The system under test (SUT) needs to authenticate with ETT using the credentials vendor1smtpsmtp@ttpds.sitenv.org / vendortesting123. After authentication, a mail needs to be sent to the specified addresses(goodaddress-plain@ttpedge.sitenv.org and noaddressfailure9-plain@dnsops.ttpedge.sitenv.org) to generate the MDN. The MAIL FROM should be vendor1smtpsmtp@ttpds.sitenv.org.
+ After the above step enter the SUT information (hostname, vendor email address, username, and address) in the profile window.
+
+Executing the testcase will fetch the MDNs from vendor1smtpsmtp@ttpds.sitenv.org inbox and deliver to the SUT using the information provided in the profile window.
+
+For EDGE SMTP MT Test 18(a) and EDGE SMTP MT Test 47(a), you need to:
+
+1. Enter your account information in the 'Profile Panel' on the test page.
+2. Review the account in the 'More Info' page.
+3. Connect to the vendor1smtpsmtp@ttpds.sitenv.org account, authenticating with using the credentials shown in more info.
+4. Send an email to dispatchedonly-plain@ttpedge.sitenv.org and noaddressfailure9-plain@dnsops.ttpedge.sitenv.org from the vendor1smtpsmtp@ttpds.sitenv.org account.
+5. Wait for a few minutes to allow the MDNs to return.
+6. Execute the test (RUN), then 'Awaiting Validation', there should be a success notification and the forwarding message.
+7. Look for negative MDNs in your inbox.
+
+- Q: We have not been able to successfully send SMTP Messages to wellformed14@ttpds.sitenv.org because we do not have a Trust Anchor and Public Certificate for this domain.
+
+We are having the same issue with noaddressfailure9-plain@dnsops.ttpedge.sitenv.org from Test 18.
+We have already loaded the certificates/trust anchor available here: https://ttpedge.sitenv.org/ttp/#/direct
+
+ * A: This is the self-signed server certificate that is used by the James server
+
+at ttpds.sitenv.org:25. Please add it to your trust store and let us know if this helps. Please
+note these test cases are Edge protocol plain SMTP-STARTTLS (not Direct)
+
+- Q: Where is the certificate for the Apache James server?
+
+ * A: The certificate for Apache James can be found here:
+
+ https://github.com/siteadmin/ett/blob/resources/certificates/common/james/ttpds.sitenv.org.james-tls.cert
+
+ - Follow-up: We configured the direct account in Thunderbird and the account which was shown in
+ “More info.” In the direct account settings, choose “default out-going” mail server to direct as
+ ttpds.sitenv.org; which is the SMTP server to the email vendoraccount@ttpds.sitenv.org.
+ Using these settings, the SUT can email to wellformed14@ttpds.sitenv.org via a direct email server,
+ emails are relayed and processing through ttps.sitenv.org. I am able to pass with this approach.
+ The James Certificate is used to encrypt the communication with SMTP/POP/IMAP protocols.
+
+- Q: SMTP MT Test 46 Certificate Issue: We have installed the Trust Anchor from the TTP site. However, when I attempt to send I got an error as unable to find domain bound certificate for this (wellformed14@ttpds.siten.org) address. Is another way to discover their certificate?
+
+ - A: This is NOT a direct endpoint. You need to send an SMTP message. If you have you passed SMTP MT 17 and 45, this test should be similar.
+
+## Direct Edge -- XDR
+
+- Q: XDR Test 16 says "Verify that Mutual TLS session is established between the Sender and the Receiver before transmitting data". I don't fully understand what has to be in place for this test. Do we need to submit a public certificate somewhere in our account that maps to a private key to tell the ETT to trust our system?
+
+ - A: You have downloaded the direct certificates. These are NOT the certs for mutual TLS. You need to download the certs from the embedded URL above the XDR Test 13 test.
+
+- Q: The end point I've been testing with is the following: https://vs-... I also just tried running the XDR Validator, and seem to be running into errors there as well.
+
+ - A: Please ensure you have installed the certificates needed for testing. The Direct certificates can be found on the Direct Home page (https://ttpedge.sitenv.org/ttp/#/direct) and the XDR certificates can be found on the Edge XDR Page, just above the 'Your system as "Sender"' button (https://ttpedge.sitenv.org/ttp/#/edge/xdr).
+
+- Q: I ran XDR 5 with his endpoint and I see this error in the logs.
+ Caused by: { code:"500" extendedCode:"0" reason:"XdsInternal error
+ SOAP Fault: com.ctc.wstx.exc.WstxParsingException: Undeclared namespace
+ prefix "soapenv" at [row,col {unknown-source}]: [1,158]" reasonPhrase:"Internal Server Error" }
+
+ * A: expand on the error message, the requirement that the format (Simple SOAP vs MTOM) be the same is specified in IHE ITI Technical Framework, Volume 2, Appendix V: V.8.1 Simple SOAP vs MTOM, "Both the request and the response messages shall use the same encoding."
+
+More readable descriptions and the background behind this requirement can be found:
+
+https://wiki.ihe.net/index.php/XDS.b_Implementation#More_on_MTOM_vs_MTOM.2FXOP
+https://wiki.ihe.net/index.php/XDS.b_Implementation#Interpreting_Web_Services_Specifications_for_XDS.b_and_XCA
+
+Most web service packages/libraries (such as Apache Axis2, etc) will make this switch automatically.
+
+- The timeout for the registry / XDS Toolkit is 60 seconds.
+
+* Q: What are the XDR, Direct From Address, email endpoints?
+
+ - A: The endpoints can be found at: https://github.com/siteadmin/ett/wiki/XDR-Endpoints
+
+The XDR MT Tests use these endpoints for destination:
+MT 13: badaddress@gfail.com
+MT 14: Provider1@direct2.sitenv.org
+MT 15: failure15@ttpds.sitenv.org
+MT 16: nomdn8@ttpedge.sitenv.org
+MT 32: badaddress@gfail.com
+MT 33: Provider1@direct2.sitenv.org
+MT 34: failure15@ttpds.sitenv.org
+MT 35: nomdn8@ttpedge.sitenv.org
+MT 36: processedonly@ttpedge.sitenv.org
+MT 37: processedonly@ttpedge.sitenv.org
+MT 38: processeddispatched6@ttpedge.sitenv.org
+MT 43: processedtimeoutfailure@ttpedge.sitenv.org
+MT 44: processedfailure@ttpedge.sitenv.org
+
+- Q: Edge XDR Test 6 (Send): I need to check the integrity, but can't because ETT tool generated HASH is in SHA-1 and is giving a mismatch error. How do I check D\* integrity test case along with b1? Is there any link to check this?
+
+ - A: For this test, all the SUT needs to do is establish an HTTPS connection using the provided certificates. Please download the certificates found at the top of the page.
+
+- Q: Edge XDR Test 5 (Receive): I am getting Request from ETT tool I validate it and genererate the below response with return type "String"
+
+Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_45f3cde8-1e8f-4f81-bfdb-c40365cc698a; type="application/xop+xml"; start="0.urn:uuid:45f3cde8-1e8f-4f81-bfdb-c40365cc698a@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse"...
+
+Want to know how to validate XDR soap header & body ?
+And also what should be response format ?
+
+ * A: Please refer to the IHE specifications and wiki for how to create/validate the XDR messages.
+
+There are a few threads in the google group that you can use for reference.
+
+- Q: Can you confirm that XDR MT Test 50a and XDR MT Test 50b require us to send 1 message with multiple intended recipients? We assume this is the approach vs. 1 message with 1 intended recipient to differentiate it from test XDR MT Test 20a and XDR MT Test 20b (positive and negative MDNs). These tests, XDR MT Test 20a and XDR MT Test 20b, appear to be redundant with regard to tests XDR MT Test 50a and XDR MT Test 50b.
+
+ - A: The tests, XDR MT 50a and XDR MT Test 50b weren’t designed for multiple recipients, each test requires an individual endpoint for testing. The intention of the XDR MT Test 50 a and XDR MT Test 50 b are to demonstrate the rigor of the SUT by sending to several recipients. The Test Procedure directs the SUT to send to one recipient using tests XDR MT Test 20 a and XDR MT Test 20 b, then to multiple recipients using XDR MT Test 50 a and XDR MT Test 50b.
+
+Note: The test script does not direct the SUT to test sending to several recipients at the same time; understanding the confusion, it is asking the SUT to send to multiple valid recipients.
+
+1. Delivery Notification: The user sends XDR messages to multiple valid recipients (XDR MT Test 50a).
+2. Delivery Notification: The user sends XDR messages to multiple invalid recipients (XDR MT Test 50b).
+
+- Q: To deliver disposition statuses asynchronously for XDR transmissions, is it expected that first a ResponseStatusType:Success is included by default in the synchronous reply or should it be omitted entirely?
+
+ - A: Based on the underlying XDR work-flow, ResponseStatusType of Success would be expected to be sent back.
+
+- Q: To which endpoint should XDR MDN’s be sent?
+
+ - A: The endpoint for each test case should be listed in the UI for each individual test case.
+
+- Q: What is a sample xml for an XDR MDN that includes both envelope and body?
+
+ * A: An example of the overall XDR package is available here:
+
+ http://wiki.ihe.net/index.php/XDS.b_Implementation#Example_Provide_and_Register_Document_Set-b_transaction
+ Instead of sending a document as they have in the example, the message disposition would be sent as defined in section 1.5.2.1.1 of this document (which includes an example):
+ https://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf
+
+- Q: When testing XDR sending, the user must click “RUN” on the tool (to generate the endpoint) and then send a message. When testing SMTP sending, it’s the opposite. The user must send the message and then click “RUN.” This inconsistency makes use of the tool more challenging.
+
+ * A: This difference in the workflows is an artifact of the underlying technologies and unfortunately not something that would be easy to change on our UI. For XDR, the endpoints must be established ahead of time or else the systems wouldn't know where to send messages. The Direct From address must be known so that the message can be properly routed within the ETT to the correct test instance while the test case is running. The ETT and Toolkit are an active part of this communication. The ETT must be primed BEFORE the communication takes place.
+
+ For SMTP, the ETT only becomes involved after the mail has been sent and is sitting in a mailbox. The SMTP communication/commands must be completed before ETT can check, or else there is nothing for ETT to find. The ETT can only step in AFTER the SMTP communication akes place.
+ The underlying protocols themselves have different workflows.
+
+- Q: I have sent my XDR message to the endpoint and receive a Registry Response. However, the ETT never moves past the Pending Refresh button no matter how many times I press it. How do I move forward?
+
+ - A: Verify that your XDR message contains the Direct Address Block and that Block is completely filled out and matches what was entered into the Test Case UI. The ETT uses the Direct Address block to route the messages; so if the values do not match, they will not be forwarded to the correct module within ETT.
+
+- Q: I used WCF to implement the XDR recipient web service. When testing XDR Test Case 4a and 4b, the process pipeline created CommunicationException and returned 400 server error to ETT before my codes get control. Here is the message from the ETT log:
+ HTTP/1.1 400 Bad Request
+ Cache-Control: private
+ Server: Microsoft-IIS/7.5
+ MIME-Version: 1.0
+ X-AspNet-Version: 4.0.30319
+ X-Powered-By: ASP.NET
+ Date: Tue, 11 Oct 2016 16:01:14 GMT
+ Content-Length: 0
+ My question is, do we need to return a RegistryResponse with status urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure, or the 400 server error should be enough for this situation?
+
+ * A: Test case 4a and 4b are negative test cases in the sense that the incoming messages are malformed and must be treated appropriately. The SUT needs to demonstrate that it has detected the abnormality and reacted appropriately (i.e. not accepting the message).
+
+- Q: I haven't figured out how to get ETT to show logs from asynchronous replies for the HISP XDR message tracking tests.
+ The fields are: _ Endpoint, _ Direct From Address, and \* Outgoing (ETT --> SUT) Direct From Address
+
+ * A: Test Case: XDR MT Test 13
+
+ Notes: The specifications detail how an error should be reported back asynchronously, but do not specify when this method should be used; therefore, it is acceptable for a system to send back a registry response failure synchronously or a message delivery failure asynchronously.
+
+ETT Action: The ETT will send a message to the SUT where the final address is non-existent.
+
+SUT Action: The SUT will respond either synchronously or asynchronously.
+If it is synchronous, a registry response failure will be sent. If it is asynchronously, a delivery failure message will be delivered.
+
+Proctor Action: The individuals operating the SUT will inform the Proctor how their system responds when a message is asked to be delivered to an address that is non-existent. In the UI, the same logs screen will be used in either the sync or the async case. Depending on whether the communication is sync or async, the Proctor will expect to see a registry response failure in the response tab of the logs (for
+sync) or a message delivery failure on the request tab of the logs (for async).
+
+Steps:
+
+1. Populate the fields. Endpoint parameter refers to the SUT’s listening
+ endpoint. Direct From Address refers to the Direct From that the SUT
+ will use if it is sending a response asynchronously. Outgoing Direct
+ From refers to the Direct From address that the ETT will use for its
+ initial outgoing XDR communication.
+
+2. Press Run button
+
+3. The XDR message is sent to the SUT.
+
+4. If you want to see the synchronous response, press logs or Pending
+ Refresh. If you are following the asynchronous option, do not press
+ anything on the UI yet. (Synchronous option is finished here.)
+
+5. The SUT now sends the asynchronous response.
+
+6. When the asynchronous response is complete, then press Pending
+ Refresh. If the message has been found, this button will turn to
+ Awaiting Validation. Pressing this will bring you to the asynchronous logs.
+
+- Q: For XDR Test Case 7 why do we not enter a full endpoint?
+
+ - A: The ETT tracks the incoming messages via the Direct Address block; however, in this case, the SUT is supposed to stop the communication before a message is sent because the certificate is bad. Since, the message should not come through, we will not have access to the Direct Address; therefore, the ETT asks for the IP address and tracks the request through that. Since, this is happening at the socket level, the full path for an endpoint is not applicable.
+
+- Q: Does anyone know whether it's required to use HTTPS for the sending tests other than 6 &7?
+
+ - A: HTTPS is required for XDR 6 and 7; however, other XDR tests can be demonstrated using HTTP or HTTPS.
+
+- Q: Where is the functionality in the ETT for testing the two requirements listed below referenced in the test procedure (https://www.healthit.gov/sites/default/files/170_315h2_Direct_Project_Edge_Protocol_and_XDRXDM_v1_2.pdf)?
+
+ - "170.315(h)(2)(i)(B) Send Using SOAP + XDR"
+ - "170.315(h)(2)(i)(B) Receive Using SOAP + XDR"
+
+ - A: That functionality is under "Edge Testing" from the ETT main menu, then the "XDR Test Cases" navbar link at the top of the page.
+
+- Q: In order to pass XDR Test Case 1, is it necessary to create XDR requests which include the selected document? Where can these samples be found?
+
+ - A: If you navigate to:
+ https://ttpedge.sitenv.org/ttp/#/validators, select CCDA R2.1 Validator, then download all files. The samples can be found in the download under: \CDAs\2015-Certification-C-CDA-Test-Data-master\Receiver SUT Test Data. Alternatively, the file is also at: https://github.com/siteadmin/2015-Certification-C-CDA-Test-Data/tree/master
+
+- Q: Specific tests require the SUT to receive an XDR message, translate it, then send back to the ETT via Direct. The sender address of the outgoing Direct message is supposed to match up with the address that we pre-registered, but the direct:to and direct:from fields in the received XDR message both contain the address testc...@edge.nist.gov. So, my understanding is that we must implement a workaround to change the sender address on the outgoing side. Is that correct?
+
+ - A: Functionality is being added to make the direct from information configurable from the UI in the HISP XDR test cases. The tests were updated to include a "From" address entry box.
+
+- Q: Unlike the other edge reliable messaging tests there is no place to configure the callback URL for the message dispositions. Is the test expecting to find a HISP with the associated endpoint or is the intent to verify that the direct:addressBlock contains the X-DIRECT-FINAL-DESTINATION-DELIVERY element?
+
+ - A: XDR MT test 48 is testing only the SUT's ability to generate three messages with unique IDs. The message dispositions are out-of-scope for this test. Once the three unique message IDs are found (or found not to be unique) the test is complete.
+
+- Q: What are the differences between tests XDR MT Test 19 and XDR MT Test 48?
+
+ - A: You run MT 19 if you're implementing Message Tracking Using Processed MDN. You run MT 48 if you're implementing Message Tracking Using "Implementation Guide for Delivery Notification".
+
+- Q: We have downloaded the keystore from the above site and configured our tomcat server to use it for secure connection; however, no secure connection can be established. We performed the tests this afternoon, around 1:30pm Central. Our endpoints are as follows:
+
+Non-secure: http://ych-qa-mu3.test.yourcareuniverse.net:9280/connex-ett/xdsb/pushDocumentSet
+
+Secure: https://ych-qa-mu3.test.yourcareuniverse.net:9283/connex-ett/xdsb/pushDocumentSet
+
+Please advise us of how to resolve this issue.
+
+ * A: We found the logs for this test case :
+
+INFO 3888 --- [io-12080-exec-1] g.n.h.ttt.xdr.api.TLSClientImpl : Sending a request to the server using socket:
+Socket class: class sun.security.ssl.SSLSocketImpl
+Remote address = ych-qa-mu3.test.yourcareuniverse.net/52.73.115.17
+Remote port = 9283
+Local socket address = /172.31.38.171:36196
+Local address = /172.31.38.171
+Local port = 36196
+Need client authentication = false
+Cipher suite = SSL_NULL_WITH_NULL_NULL
+Protocol = NONE
+javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHands
+hakeException: Received fatal alert: bad_certificate
+
+It looks like you are using a bad certificate. Please re-download the certificate and re-install it.
+
+- Q: XDR Test 3 (Revieve): We believe we having an issue Receiving the Documents and saving to the EHR. We have code to check for a document ID which has been sent in the past. Is there a way we could set the unique document ID in the test so that we can import the files more easily?
+
+ - A: The ETT uses a symbolic ID ("Document01") in the metadata to identify the attached document:
+
+
+
+It is incumbent upon the receiving registry in a provide and register transaction to turn the symbolic ID into a UUID of their choosing. In IHE ITI, Volume 2b, see Section 3.42.4.1.3.7 UUIDs and Symbolic Ids:
+
+"If a field is formatted as a symbolic Id in the Submission Request, the Document Registry shall replace it with newly generated, properly formatted UUIDs upon acceptance of the submission. If the same symbolic Id appears more than once in the Submission Request, it shall be replaced with the same generated UUID."
+
+The receiving system must be able to handle symbolic IDs in accordance with the base IHE specifications.
+
+- Q: What are the differences between tests XDR MT Test 19 and XDR MT Test 48.
+
+ - A: XDR MT Test 19 is for Message Tracking Using Processed MDN. XDR MT Test 48 is for Message Tracking Using "Implementation Guide for Delivery Notification".
+
+- Q: ETT is not succeeding for us on XDR Test 8, though we seem to be able to perform mutual SSL with the provided client certificate using OpenSSL. XDR Test 8 is not giving us much information about why it is failing. I suspect ETT is not trusting our server certificate. We have had issues before with certain systems not including GoDaddy's intermediate certificate authority, resulting in an incomplete certificate chain.
+
+ - A: The certificate provided for the XDR transactions needs to be used in both sides of the mutual TLS connection (it's loaded into our keystore and your keystore or equivalent). We don't look for your server certificate, the toolkit is already loaded with the provided, self-signed cert.
+
+- Q: In the XDR test 8 for mutual TLS, the following test step is used:
+ “Verifies the ability of the receiving system to complete a mutual TLS handshake before data is sent across. Certificates for this test can be downloaded from the link at the top of this page. As this is a socket-level test, the full endpoint is not necessary and only hostname and port are to be entered below”.
+ Where can the referenced certs be downloaded from?
+
+ * A: There is a download link above the “Your System as: Sender” with light blue text, “Click to download TLS Certificates”.
+
+- Q: XDR MT Test 30 includes a Direct To Address field, which is only used for async responses in other tests. However, my understanding is that this test is only checking that the SUT can handle the X-DIRECT-FINAL-DESTINATION-DELIVERY header, not that the resulting delivery notification is valid. Am I correct? If so, what is the purpose of the Direct To Address field?
+
+ - A: The X-DIRECT-FINAL-DESTINATION-DELIVERY header is what is checked for this test case.
+
+ The “DIRECT To:” is the direct address that is responded to and is registered/mapped in the Direct portion of the ETT.
+
+ The "Outgoing (ETT --> SUT) Direct From Address" refers to the value that we place in the element in all outgoing messages from ETT to the SUT. This may be optional for your system.
+
+- Q: Is there a sample you can provided for XDR MT TEST 30 so show what the header should look like?
+
+ - A: The soap body could itself be inspected from the "Log" section of the test by clicking the "Waiting for Validation" or "Logs" button after running the test.. Please let us know if this is not what you are looking for.
+
+ Of particular interest is this part
+
+ true
+
+ - Follow-up: In the 30 and 31, the proctor needs to verify that the headers are being processed and "accept" / "reject" based on the demonstration.
+
+ For 32 and above, the "Logs" button can be used to see the synchronous/asynchronous delivery notification produced by the System Under Test (SUT), however, the process of accept/reject still remains the same - a verification by the proctor as per IG for Delivery Notification 1.5.2.1.1.
+
+ "The proctor will read the logs for the synchronous communication or the asynchronous communication for an appropriate response. This test is part of the Implementation Guide for Delivery Notification test suite"
+
+- Q: Please confirm my understanding. The ETT for XDR MT TEST 30 sends a a VALID delivery notifications request to the system under test in the following format. The system under test then sends a Direct message based on the VALID delivery notifications request. If I am correct then is the format above that you sent me the complete VALID delivery notifications request? We are trying to give vendors a sample of what the VALID delivery notifications request looks like.
+
+ - A: Yes, that is correct; the format is same - however the multi-part identifier and other ids and direct:from/to elements will differ based on the session.
+
+- Q: The vendor does not understand XDR MT TEST 30, and I am not 100% sure of what role the Test Proctor has in the verification process. This is the message flow chart from page 11 of the IG for Delivery Notification. So...
+
+1. The ETT acts as the Receiving STA because the ETT sends a VALID delivery notifications request?
+
+2. The SUT is expected to receive this valid delivery notification, and send a success notification back to the ETT (with the ETT acting as the original sending Edge client?
+
+If this is correct then what format of the success notification is the ETT looking for? And, what verification does the proctor do since it seems that some verification is done automatically by the ETT, and other verification seems like it is visual inspection by the proctor.
+
+ * A: The complete positive delivery notification flow described is being tested in XDR MT TEST 38 (and in these cases, ETT only shows the logs and no automatic verification is being done, the proctor has to accept/reject based on visual inspection as per examples in the IG for Direct-Edge 1.5.2.1.1.)
+
+However, XDR MT TEST 30 tests only a part of it, namely that the XDR well formed header is being processed by SUT - this can be demonstrated by showing the SUT logs. Similarly XDR MT TEST 31 can be demonstrated by the SUT log message of an error in the malformed field. Technically speaking XDR MT TEST 38 subsumes XDR MT TEST 30.
+
+For XDR MT TEST 38, you are right - ETT acts as a sending Edge by requesting the Delivery Notification through the header. And SUT is expected to receive this valid notification and send it back to the ETT (acting as the Edge XDR) - which can be viewed from the tool's log button - in this case, the example of the notifications are given in the document example from IG for Direct-Edge 1.5.2.1.1.
+
+
+mailto:entity1@direct.example.org
+success
+
+
+(for negative cases, XDR MT TESTs 33-37, this would correspond to failure with an optional reason for failure as per the example)
+
+- Follow-up: The SUT is never creating a notification in MT 38 since it just forwards a copy of the notification from the ETT back to the ETT?
+
+"For XDR MT TEST 38, you are right - ETT acts as a sending Edge by requesting the Delivery Notification through the header. And SUT is expected to receive this valid notification and send it back to the ETT (acting as the Edge XDR)"
+
+ * A: SUT is copying the notification from ETT received through Direct SMTP back to ETT - but now using XDR (Edge).
+
+- Q: Where is the XDR SAML validation in the ETT?
+
+ - A: It is available in the XDR Validator in the Message Validators section:
+
+ https://ttpedge.sitenv.org/ttp/#/validators/xdr
+
+ The receive part validates the incoming SAML and the send part has the ability to include the headers in the outgoing message.
+
+- Q: The HTTPS XDR test endpoints aren't working properly, specifically XDR Tests 3 & 5.
+
+ - A: Please ensure you have downloaded the certificates and installed them. The certificates can be found at the top of each test section, beneath the ribbon bar and above the button "Your System as: Sender". Look for, "Click to download XDR TLS certificates".
+
+* Here are some examples for XDR:
+ http://wiki.ihe.net/index.php/XDS.b_Implementation#Example_Provide_and_Register_Document_Set-b_transaction_.28with_full_metadata.29
+
+ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/XDS.b/
+(Provide and register examples)
+
+## XDM
+
+- Q: My XDM is not being validated because the tooling says it cannot find the metadata, or cannot open the zip, or is not moving forward in the validation steps.
+
+ - A: Check that the IHE_XDM and SUBSET01 directories have been explicitly created. When the ZIP file is viewed, there should be a specific entry for each directory listing.
+
+* Some examples for XDM:
+ ftp://ftp.ihe.net/Connectathon/samples/XDM_samples/
+
+A table showing the difference in optionality between the different XD\* metadata is available in Vol 3 of IHE ITI:
+ See table " 4.3.1-3: Sending Actor Metadata Attribute Optionality" starting on page 109.
+
+- Q: I have tried to validate some XDM zip's, but it seems that the validator stops at point 'Decoding ZIP'.
+ It works with the sample found on ftp://ftp.ihe.net/Connectathon/samples/ITI-profiles/XDM_samples/ but if you try to decompress and compress it again, it does not work anymore.
+
+I've tried with different compressing algorithm like 'Deflate', 'Deflate64', 'LZMA', 'PPMd', 'BZIP2', but none of them works. If you try with those kind of algorithm, you will see java exceptions of the validator saying 'not supported algorithm...'
+So my question now is how to compress files to create a valid XDM-Zip?
+
+ * A: Tested working solutions are:
+
+- Using of 7-Zip (17.00 beta) -> But you have to set the 'relative path' again in the GUI.
+- Using of MacOS X line command, navigate to the folder that contains all XDM-files and use 'zip -r \*'
+- Using WinRAR 5.40 (64bit) -> make shure that value 'Store relativ path' under tab 'Files' is selected
+ The IHE specification states to use the ZIP format, not the RAR format for compression.
+
+## C-CDA
+
+- Q: How do you use the C-CDA 2.1 Validator?
+
+ * A: 1. Using the C-CDA Validator 2.1, Step 1 is to select whether you are performing a Sender specific test or Receiver Specific test (Select Sender / Receiver).
+
+ a. The above choice will make what appears when you click the “Select Document “ to change based on the SUT role.
+ b. In your case you would select “Sender”
+
+2. Then you would select the criteria first and for each criteria that you select you may have one or more PDF files.
+3. You would download the PDF file,
+4. Enter the test data provided into your SUT instance.
+5. Generate a C-CDA document. (This is C-CDA Validator Step 2)
+6. Then in the C-CDA Validator Step 3, you have to select the Criteria and the PDF file which you used to generate the C-CDA.
+7. Then upload the C-CDA file that you generated in C-CDA Validator Step 4 and then validate.
+
+The above sequence is what you would use to validate the C-CDA files you generated using the test data.
+
+If you want to validate files generated by your system without using the test data provided then you can proceed to Step 3 and select “CCDA_IG_Only” or “CCDA_IG_Plus_Vocab” options and then upload and validate. This is to help vendors prepare their systems however certification procedures require the use of the provided test data unless you work with the ATLs to file for deviations to the test data.
+
+- Q: Can multiple organizations be included as information recipients within the element?
+
+ - A: CDA allows for 0..\* information Recipients. You should include more than one informationRecipient if you’d like to send information to multiple organizations.
+
+- Q: How can CCDA xml files for interoperability modules be created to include multiple races and ethnicities?
+
+ * A: There is an extension package that may be used.
+
+ sdtc:raceCode
+ sdtc:ethnicGroupCode
+ See the C-CDA companion guide for additional details:
+ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=447
+
+- Q: I'm now trying to increase the debugging output from the validator, hopefully to see where my issues exist with the vocabulary. I've tried using a global DEBUG level in the logging.properties file and setting to ALL, but it appears that the validator doesn't look at the properties file to set it's level of logging.
+
+Does anyone know where I can change that info level for the validator classes?
+
+The logging that I do get appears to show the vocab/valuesystems loading just too quickly.
+
+08:27:14,748 INFO [VocabularyLoadRunner:92] Loading vocabularies at: /var/tomcat2/ValidatorConfig/CodeSystems...
+08:27:14,748 INFO [VocabularyLoadRunner:94] Vocabularies loaded...
+08:27:14,748 INFO [VocabularyLoadRunner:99] Loading value sets at: /var/tomcat2/ValidatorConfig/ValueSets...
+08:27:14,749 INFO [VocabularyLoadRunner:101] Value Sets loaded...
+08:27:14,749 INFO [VocabularyLoadRunner:105] !!!!****\*\*\***** VOCABULARY DATABASE HAS FINISHED LOADING - SERVER WILL CONTINUE AND SHOULD BE DONE SHORTLY. ****\*\*\*****!!!!
+
+ * A: 15:02:46,635 INFO [VocabularyLoadRunner:92] Loading vocabularies at: C:\CCDA\Validator\code_repository...
+
+15:02:46,636 INFO [VocabularyLoadRunner:44] Loading files in : CDT...
+15:02:47,758 INFO [VocabularyLoadRunner:44] Loading files in : ICD10CM...
+15:02:51,412 INFO [VocabularyLoadRunner:44] Loading files in : ICD10PCS...
+15:02:53,378 INFO [VocabularyLoadRunner:44] Loading files in : ICD9CM_DX...
+....
+C:\CCDA\Validator\valueset_repository...
+15:04:37,554 INFO [VocabularyLoadRunner:44] Loading files in : VSAC...
+15:04:37,555 INFO [VsacLoader:30] Loading Value Set File: Ability.xlsx
+15:04:37,662 INFO [VsacLoader:30] Loading Value Set File: ActPriority.xlsx
+15:04:37,708 INFO [VsacLoader:30] Loading Value Set File: ActStatus.xlsx
+...
+
+Here are my config settings for the the codes set and value set files:
+
+
+
+
+The localCodeRepositoryDir is the path to the folders (e.g. ICD9CM_DX, ICD9CM_SG, ICD10CM, etc...) that contain the code set files.
+The localValueSetRepositoryDir is the path to the VSAC folder that contains all of the value set files.
+I believe the application is hard-coded to look for those particular folders in order to process the files within. That may be case-sensitive...
+
+- Q: Hello, were there any updates made to the tool? I'm getting this same error with problem codes for "no known problems".
+
+ * A: No specific updates were made to the tool to remove the validation for the “No Known Problems”.
+
+ Are you following the HL7 example at http://hl7-c-cda-examples.herokuapp.com/examples/view/7353a215efda8dfe3fbacb19abbb90756ce14bab
+
+- Q: Hoping to obtain some clarity around representing NDC codes for administered immunizations in the C-CDA.
+
+NDC is published as a standard for immunizations as a CCDS element and the ONC's CCDS companion guide cites that it's supported as a translational element accompanying the CVX code in CDA R2.1. Looking at the 2.1 IG, NDC is referenced within the Immunization Medication Information entry-level template with the Vaccine Clinical Drug value set stating: "Value set intensionally defined from RXNORM (OID: 2.16.840.1.113883.6.88), comprised of those codes whose ingredients map to NDC codes that the CDC associates with CVX codes." Reading this and viewing the provided examples it appears as though the IG expects only RxNorm codes (not NDC) to be used as translational element entries mapping between an NDC and a CVX.
+
+NDC's are not actually included anywhere in the certification test data/validation for immunizations (only CVX), and I'm struggling to find any examples of their use for immunizations in C-CDA. Is there a specific expectation of how NDC codes are to be represented in C-CDA docs (if at all) to satisfy the ONC's CCDS standard?
+
+ * A: The test data contains CVX because that is accompanied with a SHALL requirement in the C-CDA IG.
+
+Since the translation elements are having a conformance statement of “MAY” and not a “SHALL”, you could choose to use the NDC codes mapped to the CVX codes in the translation element as specified by the CCG.
+
+## Other
+
+- Q: Question: In our implementation and definition of our Edge system and our HISP, we are not able to use the ETT as our HISP to connect to our Edge system. (This reference from the Federal Register’s published Final Rule supports our implementation: https://www.federalregister.gov/d/2015-25597/p-1114. Relevant text in the screenshot below).
+
+For XDR Test 5, the ETT "More Info" link says:
+
+Description:
+Verify that an Edge system can receive a properly formatted XDR message. The SUT will receive the XDR message with a 'direct:from' and 'direct:to' address of testcase5@ttpedge.sitenv.org. This was designed to require the SUT's endpoint as the only input parameter.
+
+Expected Result:
+Edge system is capable of receiving and processing a valid message with Full Metadata, test procedure may include other details for verification. Test Tool is satisfied with a good response.
+
+Because that is not a domain that we manage, our system is rejecting the XDR messages. To resolve this issue, we have mapped inbound XDR messages with a To address domain of @ttpedge.sitenv.org to a domain that we manage in order to successfully receive these messages. We have been able to successfully complete these tests.
+
+ * A: The demonstration of a successful receipt of the message is the benchmark. The domain mapping approach you describe is acceptable.
+
+- Q: Is it safe to send Protected Health Information (PHI) to NIST tooling?
+
+ - A: No! Never send Protected Health Information (PHI) to the ETT server. If necessary, local copies of our tooling can be downloaded and installed. DO NOT send live data to the tool on our website, there is no protection for PHI/PII.
+
+- Q: How do we differentiate between a PRN medication and a Daily once frequency medication?
+
+ - A: Right now, the presence of a ‘precondition’ with appropriate nullFlavor is an indicator for PRN without a precondition. If you have a precondition, that that is your precondition PRN – if this is a problem in your current live implementation, please come to HL7 SDWG (Thursday 10-12 PM ET - Agenda) – happy to discuss alternative approaches. " QD = daily" & "PRN = As needed"; You can have ‘Daily with a specific precondition (e.g. Back pan) or ‘Daily as-needed’
+ (aka QD PRN). If you want to present an example with precondition, we are happy to have
+ you on the HL7 examples task force.
+
+- Q: The previous test data (v9) had medications that seemed to fall either within the admission (6/22/15-6/24/15) or to be discharge medications (beginning 6/24/15 with various end dates). The v10 test data changed the dates. Was there a rationale for this change? Are the medications that start during the admission but continue after it (for example, 6/22/15-6/30/15) intended to be prescriptions or inpatient orders?
+
+ * A: Systems were encountered that were treating medications that had start dates and end dates within the inpatient stay as historical medications. Because of this, they were not sending all the medications as part of the C-CDA document generated. One of the resolutions was to make sure all the medications had an end date after the inpatient stay so that the entire list can be included as part of the C-CDA document. Some of them start during the encounter and continue beyond the encounter. The list of medications can be part of the Medications section or the
+
+ Discharge medications sections.
+
+- Q: Where can ATLs download the latest release of the ETT for local installation?
+
+ * A: The current release packages are available here:
+
+ https://github.com/siteadmin/ett/releases
+
+- Q: Now that the ETT has transitioned to hosting by SITE what inbound IPs and Ports are utilized?
+
+ - A: The port configurations remain the same, and the information regarding the URLs/certificates/endpoints are in this ONC announcement below - https://groups.google.com/d/msg/edge-test-tool/MZBY5UPsOPE/1RJkv-n8AwAJ
+
+- Q: Are there online tutorials to use for the Edge Testing Tool?
+
+ - A: Online tutorials: https://ttpedge.sitenv.org/ttp/#/validators/documents
+
+- Q: We’re having an issue Receiving the Documents and saving to the EHR. We have code to check for a document ID which has been sent in the past. Is there a way we could set the unique document ID in the test so that we can import the files more easily?
+
+ * A: The ETT uses a symbolic ID ("Document01") in the metadata to identify the attached document:
+
+ It is incumbent upon the receiving registry in a provide and register transaction to turn the symbolic ID into a UUID of their choosing. In IHE ITI, Volume 2b, see Section 3.42.4.1.3.7 UUIDs and Symbolic Ids: "If a field is formatted as a symbolic Id in the Submission Request, the Document Registry shall replace it with newly generated, properly formatted UUIDs upon acceptance of the submission. If the same symbolic ID appears more than once in the Submission Request, it shall be replaced with the same generated UUID." The receiving system must be able to handle symbolic IDs in accordance with the base IHE specifications.
+
+- Q: We’re getting an error message while trying to validate a C-CDA file- any suggestions?
+
+ - A: All prescribable medication formulations are represented using either a "generic" or "brand-specific" concept. This includes RxNorm codes whose Term Type is SCD (semantic clinical drug), SBD (semantic brand drug), GPCK (generic pack), BPCK (brand pack), SCDG (semantic clinical drug group), SBDG (semantic brand drug group), SCDF (semantic clinical drug form), or SBDF (semantic brand drug form). It does not include the PSN term type, hence the error. If PSN needs to be included, it should be an ERRATA through HL7.
+
+- Q: For Negative Testing CCDS samples 2 and 3, there is a SNOMED code "27171005" which is being validated in the ETT Message Validator as a LOINC code and throwing an error. It appears that this is a valid SNOMED code in the results section of a procedure. Will the ETT Message Validator be updated to address this issue?
+
+ - A: Negative Testing which is being performed as part of the b1 capability is to ensure that the System Under Test (SUT) is more robust and is able to receive and parse C-CDA’s more effectively including the CCDS data elements. All of the CCDS vocabulary requirements that are enforced for normal b1 sample XML files are valid for negative testing also.
+
+- Q: I tried to understand the certification criteria but got stuck with understanding 170.315(h)(1) & (h)(2). I don't understand why h1, looks like h2 is covering h1. I have couple of questions: 1. What is a edge system how to implement it? DO I HAVE TO for this MU3 Certification? 2. As of my knowledge, a HISP can be implemented by using Direct project JAVA RI, but I don't understand what an edge protocol is and how to implement? 3. All documents in the "Implementation Guide for Delivery Notification in Direct V 1.1" and the "Applicability Statement for Secure Health Transport V 1.2" are talking about HISP-SMTP, Edge-SMTP, and SOAP protocol what is the deference?
+
+ * A: The definition of an Edge system and Edge protocols are defined in Implementation Guide for Direct Edge Protocols Version 1.1 which is available here:
+
+ https://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf.
+
+ - Questions regarding the Certification Program should be addressed via email to: ONC.Certification@hhs.gov. You will also discover information at this link: https://www.healthit.gov/policy-researchers-implementers/2015-edition-test-method
+
+- Q: Attached is an Edge sample file with UNKNOWN for patient race and ethnicity. I have tried but could not find UNKNOWN any where in OMB/CDC race and ethnicity value set codes. I have tried several ways, but it is giving data validation error. Please guide us from where i can find code for UNKNOWN race and ethnicity. Is there issue in sample file data ??
+
+ - A: Please refer to the C-CDA IG for the appropriate value sets and the codes for Unknown.
+
+- Q: What is the process for configuring a SUT for Mutual TLS Authentication? I understand that the SUT can download the cert from the ETT for it to trust the tool. How does the ETT trust the SUT?
+
+ - A: That same cert will need to be loaded into the SUT as well. The same cert is used for both sides of the mutual TLS connection.
+
+- Q: Do HTTPS end points work, it isn’t working for us.
+
+ - A: Vendors need to be aware of the following when using HTTPS endpoints.
+
+1. SUT has to import the ETT published certificates to use for Mutual TLS.
+2. They need to provide these certs in the Mutual TLS handshake when using HTTPS.
+3. Sometimes when using the ETT certs, vendors encounter exceptions.
+ a. Here is an example:
+ i. When attempting to run tests in the Edge Test Tool, we added the Certificates into our system. We noticed a critical failure and were unable to send a message due to an issue we found with the cert.pem file. There is a Core Java feature that requires the contents of the subject (CN) to match the host. What we expected was CN=ttedge.sitenv.org but what we saw was CN=test.
+
+To fix the above problem identified in bullet #3, the vendor can use the approaches outlined below.
+a. If there are issues with the CN name, it is possible to map the host file (1).
+b. Alternatively make a change programmatically per the IHE recommendation (2).
+
+It is acceptable to use the hostname implementation approach or the approach identified by the IHE. Using the approach identified in the IHE wiki will allow you to interoperate with other Endpoints who follow the IHE spec and provide certificates which don’t have the right CN value.
+If you did it programmatically, you set the address as the requirement; however, the host name approach is also fine as long as you know that in the real world might encounter the same issue and you will have add more host names.
+
+(1) Please see the post below for the host file mapping solution.
+
+“What we expected was CN=ttedge.sitenv.org but what we saw was CN=test.
+
+To resolve this issue, we added a entry into our host file to map "test" to "ttpedge.sitenv.org." Please confirm this approach is acceptable.”
+
+https://groups.google.com/d/msgid/edge-test-tool/1f1c6fdd-834e-44d9-856d-57d4a07ed391%40googlegroups.com.
+
+(2) Please see the posts below for the IHE programming solution.
+How do I eliminate exceptions caused by Certificate mismatches with the server host name?
+The ATNA profile says nothing about whether the DNS name of the host must match the name specified in the certificate. It assumes that posession of the certificate with the private key is sufficient to protect the connection.
+By default, the Java HttpsURLConnection verifies the DNS name of the host against that of the certificate. If you want to disable this, the easiest way is to add the following lines of code somewhere in the initialization of your application.
+HttpsURLConnection.setDefaultHostnameVerifier(
+new HostnameVerifier() {
+public boolean verify(String hostname, SSLSession session)
+{
+return true;
+}
+ }
+);
+Alternatively you can call setHostnameVerifier on your URLConnection.
+connection.setHostnameVerifier(
+new HostnameVerifier() {
+public boolean verify(String hostname, SSLSession session)
+{
+return true;
+}
+ }
+);
+
+http://wiki.ihe.net/index.php/ATNA_FAQ#How_do_I_eliminate_exceptions_caused_by_Certificate_mismatches_with_the_server_host_name.3F
+
+https://groups.google.com/d/msgid/edge-test-tool/068f7a3c-365b-4a30-bc86-d1a6eb794590%40googlegroups.com.
+
+- Q: Does ETT has added the following accredited trust bundle into the testing system?
+
+ - A: The public certificate and trust anchors used by TTP/ETT are available here:
+
+- Q: From what I understood from the documentation, for successful execution of the test procedures for 170.315(h)(1), the direct mail server does not require STARTTLS. Can your ensure that my understanding is correct?
+
+ - A: Yes, the Direct transport does not make use of STARTTLS; while, the mail-based Edge protocols do use STARTTLS.
+
+- Q: Where can ATLs download the latest release of the ETT for local installation? Today (September 28th) the NIST hosted tool (https://ttpedge.sitenv.org/ttp/#/home) and the release notes (https://ttpedge.sitenv.org/ttp/#/edge/releaseNotes) report the current version is 1.1.0.
+
+The latest version of the JAR file found at the Bit Bucket downloads link is ett.1.0.19.jar (https://bitbucket.org/jperugini/ett/downloads?tab=downloads), which has a release date of June 24th, 3 months prior to the date of the current release.
+
+ * A: The current release packages are available here:
+
+https://github.com/siteadmin/ett/releases
+
+- Q: Does the ETT require the same unique message ID when the message is sent to multiple recipients, or is it acceptable to have different message IDs for each recipient?
+
+ - A: Message IDs must be unique.
+
+## Helpful Items
+
+- A good "cheat-sheet" resource for XD\* metadata is available at:
+ .
+- A helpful guide for navigating the XDR metadata. There are also example files in this directory:
+ ftp://ftp.ihe.net/%20TF_Implementation_Material/ITI/examples/XDS.b/ (see ProvideAndRegisterDocument\*)
+
+- Here are some examples for XDR:
+ http://wiki.ihe.net/index.php/XDS.b_Implementation#Example_Provide_and_Register_Document_Set-b_transaction_.28with_full_metadata.29
+
+ftp://ftp.ihe.net/TF_Implementation_Material/ITI/examples/XDS.b/
+(Provide and register examples)
+
+- Some examples for XDM:
+ ftp://ftp.ihe.net/Connectathon/samples/XDM_samples/
+
+A table showing the difference in optionality between the different XD\* metadata is available in Vol 3 of IHE ITI:
+ See table " 4.3.1-3: Sending Actor Metadata Attribute Optionality" starting on page 109.
+
+- Q: How do I check the SHA value of a message digest.
+
+ * A: You can use the Linux command 'sha1sum': ...IHE_XDM/SUBSET01$ sha1sum DOCUMEN.XML
+
+ 986f71360224a1bec649d9e49e91e51bce29de07 DOCUMEN.XML
+ An alternative, using a MS-Windows OS, right-click on the Document file and select 'Calculate Digest'. Selecting 'Properties' will also display the file size.
+
+- Q: My system supports direct messaging and SMTP. Is there any information out there on how to add XDR and XDM support?
+
+ * A: XDR is defined as ITI-41: Provide and Register Document Set-b. This can be found in Section 3.41 in Vol 2 of the IHE ITI Technical Framework:
+
+ XDM is defined as ITI-32: Distribute Document Set on Media. This can be found in section 3.32 of the same document.
+
+ A Google Group for implementators of these specifications can be found
+
+ here: .
diff --git a/src/components/shared/Ankle.tsx b/src/components/shared/Ankle.tsx
new file mode 100644
index 00000000..acd88d05
--- /dev/null
+++ b/src/components/shared/Ankle.tsx
@@ -0,0 +1,28 @@
+import { Box, Container, Typography } from '@mui/material'
+import Link from 'next/link'
+
+export default function Ankle() {
+ return (
+
+
+
+ Cant find what your looking for?
+
+
+ Please checkout our{' '}
+
+ FAQs
+ {', '}
+
+ Documentation & Videos
+ {', '}
+ or{' '}
+
+ Archived
+ {' section '}
+ for more details.
+
+
+
+ )
+}
diff --git a/src/components/shared/BannerBox.tsx b/src/components/shared/BannerBox.tsx
new file mode 100644
index 00000000..35e323a4
--- /dev/null
+++ b/src/components/shared/BannerBox.tsx
@@ -0,0 +1,42 @@
+'use client'
+import { Box, Breadcrumbs, Container, Typography } from '@mui/material'
+import TourButton from '@components/shared/tour/TourButton'
+export interface BannerProps {
+ breadcrumbs?: React.ReactNode
+ heading: string
+ subHeading?: string
+ isTourButton?: boolean
+ description: React.ReactNode
+}
+const BannerBox = ({ breadcrumbs, heading, subHeading, description, isTourButton }: BannerProps) => {
+ const subHeadingAndTourButtonBoxStyle = {
+ display: 'flex',
+ justifyContent: 'space-between',
+ alignItems: 'center',
+ width: '100%',
+ }
+
+ return (
+
+
+ {breadcrumbs && {breadcrumbs}}
+
+
+ {heading}
+
+ {isTourButton && }
+
+ {subHeading && (
+
+ {subHeading}
+
+ )}
+
+ {description}
+
+
+
+ )
+}
+
+export default BannerBox
diff --git a/src/components/shared/CardWithBorder.tsx b/src/components/shared/CardWithBorder.tsx
new file mode 100644
index 00000000..31661834
--- /dev/null
+++ b/src/components/shared/CardWithBorder.tsx
@@ -0,0 +1,49 @@
+import * as React from 'react'
+import Card from '@mui/material/Card'
+import CardContent from '@mui/material/CardContent'
+import Typography from '@mui/material/Typography'
+import { Button } from '@mui/material'
+import Link from 'next/link'
+
+export interface CardWithBorderProps {
+ cardHeader: string
+ description: string
+ buttonTitle: string
+ buttonLink: string
+ buttonIcon: React.ReactNode
+}
+const genericCardBlueBorder = {
+ display: 'flex',
+ width: '50%',
+ borderTop: '16px solid #122953',
+}
+
+const flexibleContent = {
+ display: 'flex',
+ flexDirection: 'column',
+ alignItems: 'flex-start',
+ justifyContent: 'space-between',
+ gap: 2,
+ p: 2,
+}
+const CardWithBorder = ({ cardHeader, description, buttonIcon, buttonLink, buttonTitle }: CardWithBorderProps) => {
+ return (
+
+
+
+ {cardHeader}
+
+
+ {description}
+ {' '}
+
+
+
+
+
+ )
+}
+
+export default CardWithBorder
diff --git a/src/components/shared/CardWithImage.tsx b/src/components/shared/CardWithImage.tsx
new file mode 100644
index 00000000..e2322ee3
--- /dev/null
+++ b/src/components/shared/CardWithImage.tsx
@@ -0,0 +1,86 @@
+import * as React from 'react'
+import Card from '@mui/material/Card'
+import CardMedia from '@mui/material/CardMedia'
+import Typography from '@mui/material/Typography'
+import { Box, CardActionArea } from '@mui/material'
+import Image from 'next/image'
+import ArrowForwardIcon from '@mui/icons-material/ArrowForward'
+import Link from 'next/link'
+
+export interface CriteriaCardProps {
+ title: string
+ cardImage: string
+ cardHeader: string
+ cardSubheader?: string
+ description: string
+ pathname: string
+ maxWidth: number
+ imageWidth: string
+ buttonTitle?: string // optional as has default
+}
+
+const CriteriaCard = ({
+ title,
+ cardImage,
+ cardHeader,
+ cardSubheader,
+ description,
+ pathname,
+ maxWidth,
+ imageWidth,
+ buttonTitle,
+}: CriteriaCardProps) => {
+ const isExternalLink: boolean = pathname.startsWith('http')
+ const defaultButtonTitle: string = buttonTitle ?? 'Go'
+
+ return (
+
+
+
+
+
+
+
+
+
+
+ {cardHeader}
+
+
+ {cardSubheader}
+
+
+ {description}
+
+
+
+
+ {defaultButtonTitle}
+
+
+
+
+
+
+
+
+ )
+}
+
+export default CriteriaCard
diff --git a/src/components/shared/CardWithImageHome.tsx b/src/components/shared/CardWithImageHome.tsx
new file mode 100644
index 00000000..5bf9ae9c
--- /dev/null
+++ b/src/components/shared/CardWithImageHome.tsx
@@ -0,0 +1,91 @@
+import * as React from 'react'
+import Card from '@mui/material/Card'
+import CardMedia from '@mui/material/CardMedia'
+import Typography from '@mui/material/Typography'
+import { Box, CardActionArea } from '@mui/material'
+import Image from 'next/image'
+import ArrowForwardIcon from '@mui/icons-material/ArrowForward'
+import Link from 'next/link'
+
+export interface CriteriaCardProps {
+ title: string
+ cardImage: string
+ cardHeader: string
+ cardSubheader?: string
+ description: string
+ pathname: string
+ maxWidth: number
+ imageWidth: string
+ buttonTitle?: string // optional as has default
+}
+
+const CardHome = ({
+ title,
+ cardImage,
+ cardHeader,
+ cardSubheader,
+ description,
+ pathname,
+ maxWidth,
+ imageWidth,
+ buttonTitle,
+}: CriteriaCardProps) => {
+ const isExternalLink: boolean = pathname.startsWith('http')
+ const defaultButtonTitle: string = buttonTitle ?? 'Go'
+
+ return (
+
+
+
+
+
+
+
+
+
+
+ {cardHeader}
+
+
+ {cardSubheader}
+
+
+ {description}
+
+
+
+
+
+ {defaultButtonTitle}
+
+
+
+
+
+
+
+ )
+}
+
+export default CardHome
diff --git a/src/components/shared/CommunicationFab.tsx b/src/components/shared/CommunicationFab.tsx
new file mode 100644
index 00000000..70aa2a3b
--- /dev/null
+++ b/src/components/shared/CommunicationFab.tsx
@@ -0,0 +1,113 @@
+'use client'
+import React, { useState } from 'react'
+import {
+ Drawer,
+ Fab,
+ Box,
+ Button,
+ Card,
+ CardMedia,
+ CardHeader,
+ CardContent,
+ Typography,
+ CardActions,
+} from '@mui/material'
+
+import SecurityIcon from '@mui/icons-material/Security'
+import ExitToAppIcon from '@mui/icons-material/ExitToApp'
+import MoreVertIcon from '@mui/icons-material/MoreVert'
+import InfoIcon from '@mui/icons-material/Info'
+import CloseIcon from '@mui/icons-material/Close'
+import LinkButton from './LinkButton'
+
+import palette from '@/styles/palette'
+
+const drawerWidth = 300
+
+const CommunicationFab: React.FC = () => {
+ const [drawerOpen, setDrawerOpen] = useState(false)
+ const placeholder = '../shared/PlaceHolderImageSITE.png'
+ const handleDrawerOpen = () => {
+ setDrawerOpen(true)
+ }
+
+ const handleDrawerClose = () => {
+ setDrawerOpen(false)
+ }
+
+ return (
+
+
+
+
+
+
+
+
+ Users love the latest UI release! Improved design, enhanced user experience, and new features are
+ receiving high praise.
+
+
+
+
+
+
+ }
+ />
+ }
+ />
+ }
+ />
+
+
+
+
+
+ Version 4 Release March 21,2024
+
+
+
+
+
+