Integrating the Healthcare Enterprise s2

IHE Technical Framework: Year 3
______

Integrating the Healthcare Enterprise

EDR Connectathon Test Cases

Revision 2007-1

28-December-2006

______

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

EDR Connectathon Test Cases
______

Contents

1 Introduction 2

2 Tests 3

2.1 EDR_Load 3

2.2 EDR_Document_Scrutiny 4

2.3 EDR_Process_EDR 5

1 Introduction

This document describes the IHE Connectathon tests for the EDR Integration Profile.

2 Tests

2.1 EDR_Load

2.1.1 Special Instructions

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.1.2 Description

The Content Creator shall create/register one patient in the proper affinity domain: SYSTEM_NAME^EDR. Use the RIS Mall to register this patient and obtain a patient identifier.

Create the appropriate document for the EDR patient.

For any of the coded values (allergies, medications, etc.) use only coded values found in the MESA/Connectathon Code Tables document. That document should list between 3 and 5 legal coded values. Do not invent codes or import other codes. If you find that document lacking, inform the Connectathon monitor about appropriate coded values for inclusion.

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

2. Create a screen capture of a rendering of the EDR document. We recognize that not all renderings will be the same.

3. Name the document EDR_kudu.xml where kudu is your Kudu system name.

4. Create a zip file named EDR_kudu.zip that contains the three documents listed above.

5. Find the Connectathon Wiki page that references EDR documents. Upload your document according to the instructions on that page. Update the Wiki page to list your document/zip file.

6. If you support XDS, complete XDS_Doc_Source_Stores_Document or XDS_Embedded_Repository_Registers_Document using the EDR document.

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

42349-1: REASON FOR REFERRAL / Patient is otherwise healthy and is exhibiting chest pain.
10164-2: HISTORY OF PRESENT ILLNESS / Patient has no history of cardiac illnes.
11450-4: PROBLEM LIST / Stress fracture, right foot (healed) , date 1-Aug-2002
Ear infection, active, date 1-Oct-2006
10160-0: HISTORY OF MEDICATION USE / Amoxicillin (250 mg tabs) / 3 times per day / oral / 1-Oct-2006 – 10-Oct-2006
10155-0: HISTORY OF ALLERGIES / Allergen: Iodinated contrast
Reaction: laryngeal oedema
Comments: Reaction occurs within 10 minutes

2.1.3 Actors

Content Creator

2.1.4 Steps

Trans 0: Use RIS Mall to register SYSTEM_NAME^EDR

Trans 0: Create EDR document for patient EDR

Trans 0: Upload zip file to Connectathon Wiki for EDR

Trans 0: Complete XDS store/register test if applicable

2.1.5 Evaluation

This will be evaluated with the EDR_Document_Scrutiny and EDR_Process_EDR tests.

2.2 EDR_Document_Scrutiny

2.2.1 Description

One assigned Connectathon Monitor will be assigned to scrutinize EDR documents. The purpose of this test is to have a single person with domain knowledge 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 PCC TF 3.

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

The Connectathon Monitor will take the files offline and perform evaluation. 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.2.2 Actors

Content Creator

2.2.3 Steps

Trans 0: Complete test EDR_Load.

Trans 0: Notify the assigned monitor that your documents are ready for scrutiny.

2.2.4 Evaluation

In the evaluation, the Connectathon Monitor is looking for features that are specified in PCC TF 3: 3.3, the section headings. The monitor is also looking for proper use of coded values.

2.3 EDR_Process_EDR

2.3.1 Special Instructions

2.3.2 Description

There are four processing options defined for the Content Consumer:

· View

· Document Import

· Section Import

· Discrete Data Import

In this test, the Content Consumer locates the EDR document produced by a single Content Creator. The Content Consumer demonstrates which of the 4 processing options are supported for the documment.

When examining the processing of the document, the Connectathon Monitor should evaluate the document with at least these items in mind:

· Sections in the document are appropriate per the definitions in PCC TF 3: 3.3

· A default style sheet is provided by the Content Creator. The Content Consumer is required to render the document with the default style sheet. As an option, the Content Consumer can render with a different style sheet.

2.3.3 Actors

Content Creator

Content Consumer

2.3.4 Steps

Trans 0: Uses the Connectathon Wiki to find the appropriate document produced by the Content Creator.

Trans 0: Extract the EDR document from the Connectathon Wiki or retrieve the documents using XDS.

Trans 0: These next steps will depend on which options are supported by the Content Consumer.

Trans 0: Content Consumer exhibits the View Option for EDR to Connectathon Monitor using the default style sheet provided by the Content Creator.

Trans 0: Content Consumer exhibits the Document Import Option for EDR to Connectathon Monitor.

Trans 0: Content Consumer exhibits Section Import Option for EDR to Connectathon Monitor.

Trans 0: Content Consumer exhibits Discrete Data Import Option for EDR to Connectathon Monitor.

2.3.5 Evaluation

In the evaluation, the Connectathon Monitor is looking for evidence that the Content Consumer can interpret the document produced by the Content Creator. That is a test of both actors. The Connetathon Monitor is then looking for evidence that the Consumer processes at least one of the options as specified in the EDR Integration Profile.

The monitor shall check for these values in the document. If the Content Consumer supports the view option, this data shall be rendered for display. Other options may not include processing each entry, so evaluation will require some judgment.

______