XDS-SD Connectathon Test Plans

IHE Technical Framework: Year 3
______

Integrating the Healthcare Enterprise

XDS-SD Connectathon Test Cases

Revision 2007.1

31-December-2006

______

Rev. 2007-1Copyright © 2006: ACC/HIMSS/RSNA
2006.12.31

XDS-SD Connectathon Test Cases
______

Contents

1Introduction

2Tests

2.1XDS/R/M_Source_GUI

2.2XDSSD_Load_Text

2.3XDSSD_Load_PDF

2.4XDSSD_Document_Scrutiny

2.5XDSSD_Process_Text

2.6XDSSD_Process_PDF

1Introduction

This document describes the IHE Connectathon tests for the XDS-SD Integration Profile.

2Tests

2.1XDS/R/M_Source_GUI

2.1.1Special Instructions

The ‘transport’ test documents (XDS/XDR/XDM Connectathon Tests) contain a test XDS/R/M_Source_GUI in which Document Source demonstrates that the it is part of a larger system and not middleware in search of an application.

In the test, the Document Source demonstrates the process of creating and storing a document for the Connectathon Monitor.

All XDS-SD Document Source actors are required to run one instance of that test.

2.2XDSSD_Load_Text

2.2.1Special Instructions

Content Creators run one instance of this test.

You need to complete this test by Tuesday at 12:00. We would prefer that you complete by Monday at 17:00 if possible. If you complete after Tuesday at 12:00, you increase your risk that Content Consumers will ignore your document, and you will be marked incomplete.

2.2.2Description

In this test, the Content Creator creates a sample scanned plain text documents which will be used in another test by Content Consumers. If you only create scanned PDF/A documents, run XDSSD_Load_PDF instead.

The Content Creator shall create/register onepatient in the proper Affinity Domain: SYSTEM_NAME^XDSSD_TEXT. Use the RIS Mall to register the patient and obtain a patient identifier.

Create the appropriate document for the XDSSD patient.

For any of the coded values use only coded values found in the MESA/Connectathon Code Tables document.Do not invent codes or import other codes. If you find that document lacking, inform the Connectathon Monitor about appropriate coded values for inclusion.

These items describe the minimum content that must be present in the XDS-SD document. Additional content is acceptable, but the document must contain the following information:

ClinicalDocument/typeId / <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>
ClinicalDocument/id / Computed value; each document has its own id
ClinicalDocument/title / “Connectathon Scanned Text Document”
ClinicalDocument/confidentialityCode / Req’d code value will be provided
ClinicalDocuent/effective Time / Computed
ClinicalDocuent/languageCode / en-US
ClinicalDocument/recordTarget/patientRole/
patient/id / extension = Patient ID value from RIS Mall patient registration
ClinicalDocument/recordTarget/patientRole/
patient/name / <given>XDSSD_TEXT</given>
<family>your Kudu system name </family>
ClinicalDocument/recordTarget/patientRole/
patient/birthTime / 1960
ClinicalDocment/author/assignedAuthor/id / Root oid of the scanning device; use your assigned oid
ClinicalDocument /author/assignedAuthor / assignedAuthoringDevice/manufacturerModelName / Your product name and model number
ClinicalDocument /author/assignedAuthor/ assignedAuthoringDevice /softwareName / Your scanning software name and version number
ClinicalDocument/component/nonXMLBody / Scanned/B64-encoded content

2.2.3Actors

Content Creator

2.2.4Steps

NULLUse RIS Mall to register SYSTEM_NAME^XDSSD_TEXT

NULLCreate a plain text XDS-SD document for patient XDSSD_TEXT, if applicable to your application. Follow the guidance provided in the table in this test descripton for the contents of some document elements.

NULLCreate a readme.txt file that lists the Patient ID, Patient Name, company name, your name, and your Kudu system name.

NULLCreate a screen capture of a rendering of the XDS-SD document. We recognize that not all renderings will be the same.

NULLName the document XDS-SD_text_kudu.xml where kudu is your Kudu system name.

NULLCreate a zip file named XDS-SD_text_kudu.zip that contains the three documents listed above.

NULLFind the Connectathon Wiki page that references XDS-SD documents. Upload your document according to the instructions on that page. Update the Wiki page to list your document/zip file.

NULLYou may now want to move on to a XDS or XDR store/register test, or an XDM Provide Document Set on Media test, if applicable

2.2.5Evaluation

There is no evaluation for this test. It is marked “Complete” when the sample is on the Wiki.

Your content will be evaluated with tests XDSSD_Document_Scrutiny and XDSSD_Process_Text.

2.3XDSSD_Load_PDF

2.3.1Special Instructions

Content Creators run one instance of this test.

2.3.2Description

In this test, the Content Creator creates a sample scanned plain PDF/A documents which will be used in another test by Content Consumers. If you only create scanned plain text documents, run XDSSD_Load_Text instead.

The Content Creator shall create/register one patient in the proper Affinity Domain: SYSTEM_NAME^XDSSD_PDF. Use the RIS Mall to register the patient and obtain a patient identifier.

Create the appropriate document for the XDSSD patient.

For any of the coded values, use only coded values found in the MESA/Connectathon Code Tables document. Do not invent codes or import other codes. If you find that document lacking, inform the Connectathon Monitor about appropriate coded values for inclusion.

These items describe the minimum content that must be present in the XDS-SD document. Additional content is acceptable, but the document must contain the following information:

ClinicalDocument/typeId / <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>
ClinicalDocument/id / Computed value; each document has its own id
ClinicalDocument/title / “Connectathon Scanned PDF Document”
ClinicalDocument/confidentialityCode / Req’d code value will be provided
ClinicalDocuent/effective Time / Computed
ClinicalDocuent/languageCode / en-US
ClinicalDocument/recordTarget/patientRole/
patient/id / extension = Patient ID value from RIS Mall patient registration
ClinicalDocument/recordTarget/patientRole/
patient/name / <given>XDSSD_PDF</given>
<family>your Kudu system name </family>
ClinicalDocument/recordTarget/patientRole/
patient/birthTime / 1960
ClinicalDocment/author/assignedAuthor/id / Root oid of the scanning device; use your assigned oid
ClinicalDocument /author/assignedAuthor / assignedAuthoringDevice/manufacturerModelName / Your product name and model number
ClinicalDocument /author/assignedAuthor/ assignedAuthoringDevice /softwareName / Your scanning software name and version number
ClinicalDocument/component/nonXMLBody / Scanned/B64-encoded content

2.3.3Actors

Content Creator

2.3.4Steps

NULLUse RIS Mall to register SYSTEM_NAME^XDSSD_PDF

NULLCreate a plain text XDS-SD document for patient XDSSD_PDF, if applicable to your application. Follow the guidance provided in the table in this test descripton for the contents of some document elements.

NULLCreate a readme.txt file that lists the Patient ID, Patient Name, company name, your name, and your Kudu system name.

NULLCreate a screen capture of a rendering of the XDS-SD document. We recognize that not all renderings will be the same.

NULLName the document XDS-SD_pdf_kudu.xml where kudu is your Kudu system name.

NULLCreate a zip file named XDS-SD_pdf_kudu.zip that contains the three documents listed above.

NULLFind the Connectathon Wiki page that references XDS-SD documents. Upload your document according to the instructions on that page. Update the Wiki page to list your document/zip file.

NULLYou may now want to move on to a XDS or XDR store/register test, or an XDM Provide Document Set on Media test, if applicable

2.3.5Evaluation

There is no evaluation for this test. It is marked “Complete” when the sample is on the Wiki.

Your content will be evaluated with tests XDSSD_Document_Scrutiny and XDSSD_Process_PDF.

2.4XDSSD_Document_Scrutiny

2.4.1Description

One specific Connectathon Monitor will be assigned to scrutinize XDS-SD documents. The purpose of this test is to have a single person examine one example of each document. The Connectathon Monitor is looking for proper document structure, proper use of coded values and any other CDA or IHE specific requirements defined in XDS-SD Profile.

The Content Creator should use the same documents produced and stored in the Connectathon Wiki in the XDSSD_Load test.

The Connectathon Monitor will take the files offline and perform evaluation. The schematron you ran for MESA tests may be used here as well. The Monitor will document any deficiencies and ask the Content Creator to correct during the Connectathon.

This test needs to be completed by Tuesday at 12:00, and is better completed Monday afternoon if possible. This will give downstream Content Consumers better test documents.

2.4.2Actors

Content Creator

2.4.3Steps

NULLComplete test XDSSD _Load.

NULLNotify the assigned Monitor that your documents are ready for scrutiny by marking this test as ‘Complete’.

2.4.4Evaluation

In the evaluation, the Connectathon Monitor is looking for features that are specified in ITI XDS-SD Profile: 7.1.8.

2.5XDSSD_Process_Text

2.5.1Special Instructions

2.5.2Description

In this test, the Content Consumer locates the XDS-SD plain text document produced by a single Content Creator.

If the Content Creator also produces wrapped PDF/A, you can run test XDSSD_Process_PDF in parallel.

The Content Consumerrenders the document or performs some other useful function with the document.

2.5.3Actors

Content Creator

Content Consumer

2.5.4Steps

NULLUses the Connectathon Wiki to find the appropriate document produced by the Content Creator.

NULLExtract the XDS-SD document from the Connectathon Wiki or retrieve the documents using XDS/XDR/XDM.

NULLThe Content Consumer renders the document or performs some other useful function with the document. You may need to use your imagination here; this is not specified in the Technical Framework.

2.5.5Evaluation

In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can retrieve/process the document produced by the Content Creator. That is a test of both actors.

The Connectathon Monitor may check for some values that were encoded in the CDA header:

ClinicalDocument/title / “Connectathon Scanned Text Document”
ClinicalDocument/confidentialityCode / Req’d code value will be provided
ClinicalDocuent/effective Time / Computed
ClinicalDocument/recordTarget/patientRole/
patient/id / extension = Patient ID value from RIS Mall patient registration
ClinicalDocument/recordTarget/patientRole/
patient/name / <given>XDSSD_TEXT</given>
<family>your Kudu system name </family>
ClinicalDocument/recordTarget/patientRole/
patient/birthTime / 1960
ClinicalDocment/author/assignedAuthor/id / Root oid of the scanning device; use your assigned oid
ClinicalDocument /author/assignedAuthor / assignedAuthoringDevice/manufacturerModelName / Scanner’s product name and model number
ClinicalDocument /author/assignedAuthor/ assignedAuthoringDevice /softwareName / Scanner’s scanning software name and version number
ClinicalDocument/component/nonXMLBody / That the content of the scanned document itself is processed/displayed on the Consumer.

2.6XDSSD_Process_PDF

2.6.1Special Instructions

2.6.2Description

In this test, the Content Consumer locates the XDS-SD PDF/A document produced by a single Content Creator.

If the Content Creator also produces wrapped plain text you can run test XDSSD_Process_Text in parallel.

The Content Consumer renders the document or performs some other useful function with the document.

2.6.3Actors

Content Creator

Content Consumer

2.6.4Steps

NULLUses the Connectathon Wiki to find the appropriate document produced by the Content Creator.

NULLExtract the XDS-SD document from the Connectathon Wiki or retrieve the documents using XDS/XDR/XDM.

NULLThe Content Consumer renders the document or performs some other useful function with the document. You may need to use your imagination here; this is not specified in the Technical Framework.

2.6.5Evaluation

In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can retrieve/process the document produced by the Content Creator. That is a test of both actors.

The Connectathon Monitor may check for some values that were encoded in the CDA header:

ClinicalDocument/title / “Connectathon Scanned PDF Document”
ClinicalDocument/confidentialityCode / Req’d code value will be provided
ClinicalDocuent/effective Time / Computed
ClinicalDocument/recordTarget/patientRole/
patient/id / extension = Patient ID value from RIS Mall patient registration
ClinicalDocument/recordTarget/patientRole/
patient/name / <given>XDSSD_PDF</given>
<family>your Kudu system name </family>
ClinicalDocument/recordTarget/patientRole/
patient/birthTime / 1960
ClinicalDocment/author/assignedAuthor/id / Root oid of the scanning device; use your assigned oid
ClinicalDocument /author/assignedAuthor / assignedAuthoringDevice/manufacturerModelName / Scanner’s product name and model number
ClinicalDocument /author/assignedAuthor/ assignedAuthoringDevice /softwareName / Scanner’s scanning software name and version number
ClinicalDocument/component/nonXMLBody / That the content of the scanned document itself is processed/displayed on the Consumer.

______