EPLC_Interface_Control_Doc_v2.1.doc

DOC document 172 KB Posted

Attached to
FDA Center Submission Tracking and Reporting (CSTAR)
Solicitation number
FDA-SOL-11-1085941
Issued by

About this file

EPLC Interface Control Doc

View the file

Other files

File Type Posted
Responses to Questions.doc DOC document
EPLC_SLA_MOU_v . .doc DOC document
EPLC_System_Req_Spec_v2.1.doc DOC document
EPLC_SORN_C04_NO TEMPLATE.doc DOC document
EPLC_Contingency and Disaster Recovery Plan_v . .doc DOC document
EPLC_Systems Concept of Operations —
EPLC_System_Design_Doc_v . .doc DOC document
SF1449.pdf PDF
Attachment 2 CSTAR Task Order 1 SOW.doc DOC document
EPLC_System_Test_Report_r . _v . .doc DOC document
Attachment 5 FDA CSTAR Pricing Worksheet.xls XLS spreadsheet
EPLC_Business_Cases_v . .doc DOC document
Attachment 9 - CSTAR Labor Category Descriptions.doc DOC document
EPLC_Unit_Test_Report_r . _v . .doc DOC document
EPLC_Disaster Recovery Plan_v . .doc DOC document
EPLC Section 508 Test Results Template 1 .doc DOC document
EPLC_PPA_Initial Release_Waterfall.xls XLS spreadsheet
EPLC Security_Risk_Assessment_v . .doc DOC document
EPLC_Master_Test_Plan_v . .doc DOC document
Attachment 4 CSTAR Task Order 3 SOW.doc DOC document
CSTAR CCB Charter.doc DOC document
EPLC Project Schedule Template_Initial DME Release.mpp MPP file
EPLC Project Security Catagorization.xls XLS spreadsheet
EPLC_TEST CASES_T04_NO TEMPLATE.doc DOC document
EPLC Plan_of_Action_and_Milestones_Template.xls XLS spreadsheet
EPLC_Project_Mgmt_Plan_v . .doc DOC document
ATTACHMENT 7 - Past Performance Questionnaire.doc DOC document
EPLC_System_Security_Plan_v . .doc DOC document
Attachment 8 - Contractor's Commitment to Protect Non-Public Information Agreement.pdf PDF
EPLC_User_Manual_v . .doc DOC document
EPLC_Performance Test Report_T09_NO TEMPLATE.doc DOC document
EPLC_AOA_v . .doc DOC document
EPLC_Training_Plan_v . .doc DOC document
Attachment 3 CSTAR Task Order 2 SOW.doc DOC document
EPLC_Boundary_Document_v3 0.doc DOC document
EPLC_Version_Desc_Doc_v1.0.doc DOC document
Attachment 6 - PROPOSAL INTENT RESPONSE FORM.doc DOC document
EPLC_Training Materials_T15_NO TEMPLATE.doc DOC document
EPLC_Requirements_Traceability_Matrix_Template.xls XLS spreadsheet
EPLC_Implementation_Plan_v . .doc DOC document
EPLC_Business Requirements Document.doc DOC document
EPLC_Security Auth Exec Summary_IM04_NO TEMPLATE.doc DOC document
EPLC_UAT_T11_NO TEMPLATE.doc DOC document
_EPLC Overview for Contracts_v1.1.pdf PDF
EPLC_Logical Data Model_R01_NO TEMPLATE.doc DOC document
EPLC_OM_Manual_v . .doc DOC document
EPLC_Project_Charter_v . .doc DOC document
EPLC DoS Section 508 Compliance Test Plan Template 1 .doc DOC document
EPLC_Architecture_Doc_v . .doc DOC document
EPLC E-Authentication.xls XLS spreadsheet
Show 40 more

Latest 50 of 56 listed here. See the rest on GovTribe.

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Food and Drug Administration

<Project Name & Release Version #> Enterprise Performance LifeCycle

INTERFACE CONTROL DOCUMENT

Document Version Number: <#.#> Document Version Date: <mm/dd/yyyy> Notes to the Author

[This document is a template of a Interface Control Document for a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.

· Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.

· Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular project.

· Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.

When using this template, the following steps are recommended:

1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field document values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected) select File->Properties->Summary and fill in the appropriate fields within the Summary and Custom tabs.

After clicking OK to close the dialog box, update all fields throughout the document selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking on it and pressing F9.

These actions must be done separately for any fields contained with the document’s Header and Footer.

2. Modify boilerplate text as appropriate for the specific project.

3. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.

4. To update the Table of Contents, right-click on it and select “Update field” and choose the option - “Update entire table”.

5. Before submission of the first draft of this document, delete this instruction section “Notes to the Author” and all instructions to the author throughout the entire document.

VERSION HISTORY

[Provide information on how the development and distribution of the Interface Control Document will be controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.] Version Number Implemented

By Revision

Date Approved

By Approval

Date Description of and

Reason for Change

10/29/2010
10/29/2010
<Project Manager name>
<mm/dd/yyyy>
Correction made in the title page. The version should be #.#

Table of Contents

51.0 Purpose and Scope

52.0 System Interface Details

63.0 System Interface Requirements

74.0 System Interface Specifications

75.0 System Interface Security

11Appendix D – System Interface (Details) Matrix

11System Interface (Details) Matrix

12Appendix E – System Interface Requirements Matrix

12System Interface Requirements Matrix

13Appendix F: System Interface Mapping Matrix

13System Interface Mapping Matrix

14Appendix G – System Interface Specification Matrices

14Program Design Matrix

14Database Design Matrix

15User Interface Design Matrix

15Security and Integrity Design Matrix

15System Capabilities Matrix

1.0 Purpose and Scope

The purpose of this document is to define the details of interfaces for an information system. For the <PROJECT OR SYSTEM NAME> project, the following interfaces are within the project scope:

· <SYSTEM NAME>

· <SYSTEM NAME>

· <SYSTEM NAME>

Refer to Figure 1 – System Interfaces for the <PROJECT OR SYSTEM NAME> Project, which displays all the known interfaces that are part of this project.

Figure 1 - System Interfaces for the

<PROJECT OR SYSTEM NAME> Project

2.0 System Interface Details

This section of the System Interface Document provides the data fields that the <PROJECT OR SYSTEM NAME> project’s information system will require, replace, or provide to other software applications or information systems.

[This section outlines the methods for gathering the interface details that will be recorded. Describe which tools, resources, and techniques that will be used to gather this data. Some of the sources could include

· Systems Experts – via interviews and work sessions

· System Architecture Diagram

· Database Dictionaries

Also include where these items are located (network location, Configuration Management System, etc)]

[If the System Interface Details are collected and stored within a tool, identify the tool, and reference the name and location of the file that details the interfaces needed for the project. If such a source is not available, use the table in Appendix D.]

Refer to Appendix D for a detailed list of the interface items.

3.0 System Interface Requirements

This section of the System Interface Document provides the functional and technical requirements for each interface within the <PROJECT OR SYSTEM NAME>. The System Interface Requirements Matrix and the System Interface Mapping Matrix, both located in Appendices B and C, list the functional and technical requirements for each interface. A majority of the interfaces perform data transfers. This exchange of data between the software application or information systems should be mapped by using one or more of the following: <identify which methods will be used on the current project>

· A one-to-one correspondence between fields in the two systems

· A formula that combines the results of multiple fields in one system to derive the value for one field in the other system

· An algorithm that transforms the value of a field in one system to meet the requirements of the second system

· A lookup table

Other interface types should be documented and may include: <identify which types will be used on the current project.>

· Control Interfaces – An interface that allows one software application to operate another software application.

· Document Management Interfaces – An interface that allows a single container to hold multiple data types, and provide facilities for the exchange of information between multiple software applications using standards such as OLE and OpenDoc

· Device Management Interfaces – An interface that allows software application control of physical devices such as thermostats and lighting.

[If the System Interface Requirements and Maps are collected and stored within a tool, identify the tool, and reference the name and location of the file that details the interfaces needed for the project. If such a source is not available, use the tables in Appendix E and F.]

Refer to Appendix E for a list of the System Interface Requirements Matrix and Appendix F for the System Interface Mapping Matrix.

4.0 System Interface Specifications

This section of the System Interface Document specifies how each interface will work, as well as the technology and approach that will be used to develop each interface. The main matrices are:

· Program Design

· Database Design

· User Interface Design

· Security and Integrity Design

· System Capabilities

The Program Design Matrix includes the hardware, communications, and third-party utilities that are used on this project. The System Capabilities Matrix should identify and show where the design meets each of the requirements.

Refer to Appendix G for a list of the approaches for gathering the interface specifications.

[If the System Interface Specifications are collected and stored within a tool, identify the tool, and reference the name and location of the file that details the information for the project. If such a source is not available, use the tables in Appendix G.]

5.0 System Interface Security

This section describes the trust relationships that must be agreed to by the systems that are exchanging or providing data. This portion of the template must include a general information/data description, the services offered by both parties, the sensitivity of the data or information to be exchanged, the user community affected or involved, the specific information exchange security measures that will be applied, and the trusted behavior expectations of both parties (formal security policies that apply, incident reporting procedures, and audit trail responsibilities.

Refer to Appendix H <and any other appendices> for the Interconnection security agreements.

[A security agreement should be filled out for each interface. Use the agreement found in Appendix H and includes as many appendices as needed for each interface.]

APPENDIX A: Interface Control Document Approval TC "APPENDIX A: Interface Control Document Approval" \f C \l "1" [The undersigned acknowledge that they have reviewed the <Project Name> Interface Control Document and agree with the information presented within this document. Changes to this Interface Control Document will be coordinated with, and approved by, the undersigned, or their designated representatives.] Signature:

Date:

Print Name:

Title:

Role:
Project Manager

APPENDIX B: REFERENCES TC "APPENDIX B: REFERENCES" \f C \l "1" [Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.]

The following table summarizes the documents referenced in this document.

Document Name
Description
Location
<Document Name and Version Number>
<Document description>
<URL to eRoom where document is located>

APPENDIX C: KEY TERMS TC "APPENDIX C: KEY TERMS" \f C \l "1" The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

Term
Definition
[Insert Term]
<Provide definition of term and acronyms used in this document.>

Appendix D – System Interface (Details) Matrix

[Include a copy of the following matrix for each interface.]

System Interface (Details) Matrix

Table / Field Name
Schema Owner
Field Label
Data Type
Field Format
Description
Integrity Constraints
Validity Checks

The System Interface Matrix documents the following:

· Table / Field Name – The name of the table or data field.

· Schema Owner – The name associated with the creation of the schema.

· Field Label - The label for the field commonly displayed on screens and reports.

· Data Type - The data type as defined by the software application or data dictionary.

· Field Format – The field format masks for numeric, date, character, and other field types.

· Description - A short definition of the data field contents.

· Integrity Constraints - Constraints may include: NOT NULL, UNIQUE KEY and CHECK.

· Validity Checks – The checks may include allowable values, ranges, and lookup tables

Use the System Architecture diagram as a starting point for identifying each interface. Determine the data, graphics, audio, or video format for each element, and identify the communications protocols used by each application. In most cases the interface elements will be data fields, and can be identified through data dictionary reports or other miscellaneous system documents.

Appendix E – System Interface Requirements Matrix

[Include a copy of the following matrix for each interface.]

System Interface Requirements Matrix

Interface Type
Run Once or Ongoing?
Run Frequency (for Ongoing)
Sequencing Dependencies
External Systems Interface Requirements

The System Interface Requirements Matrix documents the following:

· Interface Type – Identifies the interface as a Service, Controls, Management, or Device Automation interface.

· Run Once or Ongoing – Designates whether the interface will run once for conversion or be ongoing.

· Run Frequency (for Ongoing) – Designates the run frequency (online or scheduled batch process) for ongoing interfaces. Consider the volume of data, and network and hardware capabilities along with the software application / information system requirements.

· Sequencing Dependencies – Identifies the sequence and any dependencies related to an interface.

· External Systems Interface Requirements – Identifies any requirements for interfaces to external systems (OMB, HHS, etc.) Be sure to note any applicable FDA Data Standards Council data-exchange or terminology standards. [Note: A list of data-exchange and terminology standards is available from the OIM EA Team.] Appendix F: System Interface Mapping Matrix

[Include a copy of the following matrix for each interface.]

System Interface Mapping Matrix

Table / Field Name
Schema Owner
Field Label
Data Type
Field Format
Mapping
Table
Field Name

The requirements include an interface elements mapping that is builds on the Interface Elements List. Using form PKG0056, map the interface elements by completing the last three columns of the table below.

The System Interface Mapping Matrix documents the following:

· Table / Field Name – The name of the table or data field.

· Schema Owner – The name associated with the creation of the schema.

· Field Label - The label for the field commonly displayed on screens and reports.

· Data Type - The data type as defined by the software application or data dictionary.

· Field Format – The field format masks for numeric, date, character, and other field types.

· Mapping – Designates the type of mapping between the software applications / information systems (e.g., substring, one-to-one, algorithm, etc.)

· Table - The name of the table stored in the data dictionary of the other software application / information system.

· Field Name

· – The name of the data field stored in the data dictionary of the other software application / information system.

Appendix G – System Interface Specification Matrices

[Include a copy of the following matrix for each interface.]

The System Interface Specification Matrices specify how each interface will work, and the technology and approach that will be used to develop each interface. The following matrices provide the information needed to construct the ongoing interfaces:

Program Design Matrix

Hardware

Communications

Third-Party Utilities

Programming Approach

System Capability

Technology

Database Design Matrix

DBMS

Database Design Approach

Programming Approach

How the interface works

Technology

User Interface Design Matrix

Screens

Programming Approach

System Capability

Technology

Security and Integrity Design Matrix

Security Approach

Design

Programming Approach

System Capability

Technology

System Capabilities Matrix

Requirements met by Design

Programming Approach

System Capability

Technology

APPENDIX H: <System Name> and <Interfaced System> Interconnection Security Agreement Below is a copy of the <System Name> and <Interfaced System> Interconnection Security Agreement (ICA) between <System Name> and <Interfaced System>.

<OPDIV or Center>

INTERCONNECTION SECURITY AGREEMENT

BETWEEN

<System Name>

And

<Interfaced System>

SECTION 1 – INTERCONNECTION STATEMENT OF REQUIREMENTS.

The requirement for interconnection between <System Name> and the <Interfaced System> is for the express purpose of exchanging data between these applications.

SECTION 2 – SYSTEM SECURITY CONSIDERATIONS

a. General Information/Data Description.

[Provide general information of the interface between the system and what data is being exchanged.]

<System Name> and <Interfaced System> Interface

b. Technical Requirements

[Include a list and description of any technical requirements, including any triggers or calls for data that may take place.]

c. User Community.

[Specify the specific group(s) of users that will be using this interface.]

e. Information Exchange Security.

[Describe any access to exchange data between systems.]

f. Trusted Behavior Expectations.

[Describe how data is being protected and which regulations or security policies that have been adhered to.]

g. Formal Security Policy.

[List any policy documents that govern the protection of data.]

h. Incident Reporting.

[Discuss how security incidents will be reported and which guidelines for reporting are being used.]

SECTION 3 – TOPOLOGICAL DRAWINGS

[Include diagrams that represent the architecture of the interface.]

SECTION 4 – APPROVALS

[Include signatures from Project Managers for both systems.]

Signature:

Date:

Print Name:

Title:

Role:
Project Manager

Signature:

Date:

Print Name:

Title:

Role:
Business Owner

Template Version 2.1 (Last Modified on Oct 29, 2010)

PAGE

File details come from the government source that posted it. Updated .