# Presentation: 926457

## Applicant System to System Workshop

*Applicant System to System Workshop*

- March 11, 2004

*Managed by the U.S. Department of Health and Human Services**Fulfilling the President’s Management Agenda*

## Agenda

- Welcome
- Grants.gov Overview/Update
- FDP S2S Requirements Presentation
- UCLA S2S Requirements Presentation
- MIT Grantee Back-Office System
- Break
- Grants.gov S2S Alternatives Discussion
- Open Discussion
- Review Responses to MIT Questions
- Grants.gov Questions
- Next Steps

## Grants.gov Overview/Update

*Grants.gov Overview/Update*

- Charles Havekost

## The Grants.gov Initiative

- President’s Management Agenda and PL106-107
- 11 Partner Agencies: HHS, DoD, Ed, HUD, DOJ, DOT, USDA, DOC, DOL, DHS, and NSF
- 2 main deliverables:
- A unified way to Find grant opportunities – a single place to search all competitive grant opportunities.  Available Now!  OMB policy required agencies to post starting Nov 7, 2004.
- A unified way to electronically submit grant applications. October 2003 Roll-Out Successful!

## Objectives Achieved – All On Time!

- Finalize the Grants.gov Business Case (4/15/02)
- Evaluate existing capabilities, including COTS (6/1/02)
- Pilot a simple, unified way to find federal grant opportunities via the Web (7/1/02)
- Define application data standards (10/1/02)
- Work with E-Authentication PMO and privacy groups [ongoing]
- Deploy simple, unified application mechanism (10/03)

## Accomplishments & Stats

- “Find” Pilot & Launch -- 16 months
- “Apply” Prototype, Pilot & Launch – 6 months
- 24 Application Packages Published on Grants.gov
- 18 Applications Received since October Launch
- Over 2200 Funding Opportunities Published on Grants.gov

*Challenges*

- Registration Timing
- Applications from Individuals
- Applicant System-to-System

## Cross Agency Data Sets

- Core – SF-424, Available today
- Research & Related – Version 1 Hand-off Expected by the end of the week
- Sub Research & Related – Under Development with NSF, USDA, NIH
- Mandatory Data Set – Under Development with 106-107 Workgroup
- Arts & Humanities – Under Development
*Despite work on Cross-Agency Sets, Agency-Specific Application Requirements are a big problem *

## Stovepiped Grants Environment

*Stovepiped Grants Environment*

- Applicant S2S Workshop     PAGE

## Grants.gov Solution

*Grants.gov Solution*

- Grants.gov
- “Trusted Broker”

- Applicant 1

- Applicant N

- Applicant 3

- Applicant 2

**.....**

- Applicant 2

- Applicant 3

- Applicant N

**.....**

- Agency 1

**.....**

- Agency 2

- Agency 3

- Agency N

- Builds applicant knowledge of "core" data
- Helps identify commonalities among agency-specific data

-  Embodies Standards
- Facilitates System-to-System Interfaces

*Benefits Both Grant Applicants and Agencies *

- Applicant S2S Workshop     PAGE

## Spectrum of Sophistication

*Spectrum of Sophistication*

**No Automated System**

**Existing System or 3****rd**** Party Grant Application Package**

- Printable format

**No Automated System**

**Legacy or 3****rd**** Party Grants Management Package**

- PureEdge
- Forms

- B2B XML
- System Interface

- B2B XML
- System Interface

**Small/Novice Applicant**

**Large/Sophisticated Applicant**

**Paper-based Agency**

**Fully Electronic Agency**

- Grants.gov
- “Trusted Broker”

- Applicant S2S Workshop     PAGE

## Agency Person-to-System Interface

- Grants.gov Web interface Provides Package:
- Data in XML, Attachments, PDF Document

*Agency System-to-System Interface*

- Reference Implementation
- Web Services & XML – SOAP plus Attachments
- 4 Agencies Completed Testing – USDA, HHS/ACF, ED, and HHS/HRSA
- Platforms -- Java & .Net

## Applicant Person-to-System Interface

- PureEdge Forms
- Single Account and Process
- Better Than Paper – identifies required forms/fields
- Requires Submission by AOR
- Off-line Preparation
- Only Windows viewer
- Limited Workflow, not ideal for all Grantees

## Applicant System-to-System Interface

- Our Challenge Today
- Gather Requirements
- Review Possible Alternatives
- Learn About Applicants Back-Office Systems
- Identify the “Fertile Ground” for S2S Pilot

## Grants.gov S2S WorkshopMarch 11, 2004

- Jerry Stuck
- Federal Demonstration Partnership

## FDP Mission

- A formal collaboration between federal agencies and research institutions
- 92 Research Institutions and 10 Federal Agencies
- Reduce administrative burden while providing streamlined, efficient, and effective ways to interact between the higher education community and the federal government

## Vision

- Reiterate our long-standing support of the single face of government and Grants.gov

## Roles

- Grantee System
- Submits semantically valid proposal to Grants.gov
- Grants.gov
- Assures that:
- Proposal came from trusted server
- Proposal is semantically valid
- Forwards proposal to Agency System
- Agency System
- Assures proposal is semantically valid
- Populates agency system

## Business Rules - Options

- Error Processing
- If proposal is not semantically valid, identify errors and inform submitting institution
- Allow for revision and resubmission, if business rules permit
- Enforcement of Business Rules
- How much is done at Grants.gov and how much is done at the Agency?

## System Overview

- Trust must be established between Grants.gov and Grantee Systems
- Affirmation
- Grantee affirms that any submission has been approved for submission
- Submission Method
- No position on specific method
- NIH token-retrieval system seems to allow for better management of deadline bandwidth

## Schema Management

- XML is extensible
- Can be a negative if individual agencies unilaterally extend schema
- We need a starting point, not perfect but good enough
- Schemas evolve over time
- Changes must be managed centrally with agreed upon change management process
- During initial deployment, changes will likely occur more frequently until schema stabilizes
- Schema must allow for agency requirements

## Implementation Issues

- We need a standard way of identifying key personnel
- Avoid the current proliferation of authentication credentials among agency systems
- We endorse the continued use of the BPN for institutional registration and identification
- Avoid proliferation of institutional registration and identification methods among agency systems
- Signatures – Multiple agency implementations

## Questions

## UCLA’s: Grants.govSystem-to-SystemRequirements 

- Richard Valenzuela
- Chief Information OfficerUCLA-Office of Research Administration
- March 11, 2004

## Introduction

- A system-to-system interface must be _standardized_ in architecture and functionality, and support a wide range of feeder systems to a common recipient system.
- Different organizations are expected to use different feeder systems, and as such, a _file transmission_ versus a document style transmission is expected.
- Feeder system file transmission examples include:Coeus  – EDI file transmission to NSF/NIHInfoEd – SBIR system-to-system file transmission to NIH

**Notes:**
Two Phase plan:  37 months  10/03 & 6/05
Influences:	ORA Customer	Federal Government
Value Oriented systems:	Cash Management
	Electronic Proposal Submission
Position IT resources for LT and ST efforts

## Summary of Requirements

- Standardization of Data Sets
- Technical Industry Standards Utilized
- Validation of File Submission and Receipt
- Security Channel is Fully Defined
- Grants.gov role Pass-Through or Authoritative?
- Proposal Lock-Down Functionality like CGAP?
- Redundant and Scalable with 99.999% Uptime
- Fully Defined SDLC Change Control Process

**Notes:**
Two Phase plan:  37 months  10/03 & 6/05
Influences:	ORA Customer	Federal Government
Value Oriented systems:	Cash Management
	Electronic Proposal Submission
Position IT resources for LT and ST efforts

##  Standardization of Data Set 

- Standardization at Cross Agency Set
- Variable Data Elements at Agency Specific Set
- Variable Data Elements at Program Specific Set
- Feeder system should be transparent to Recipient system
- Will this Protocol be used for award data?

**Notes:**
Facilitate Support
Reporting
Optimize resources
Automation of steps

## Technical Industry Standards

- IEEE – General Standards via membership/referenced in W3C, ISO, etc: _[http://standards.ieee.org/](http://standards.ieee.org/)_
- W3C – The World Wide Web Consortium: “Web Services for Interactive Applications.”  _[http://xml.coverpages.org/wscm.html](http://xml.coverpages.org/wscm.html)_
- ISO – International Organization for Standards: “Information processing systems-- Telecommunications and information exchange between systems ISO 9542:1988”_[http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17285&ICS1=35&ICS2=100&ICS3=30](http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17285&ICS1=35&ICS2=100&ICS3=30)_
- “System-to-System” query from ISO web site: _[http://www.iso.ch/iso/en/StandardsQueryFormHandler.StandardsQueryFormHandler](http://www.iso.ch/iso/en/StandardsQueryFormHandler.StandardsQueryFormHandler)_
- ANSI – American National Standards Institute:  ”Pursuant to OMB Circular A119, federal government agencies are required to use voluntary standards for regulatory and procurement purposes when appropriate.” _[http://www.ansi.org/about_ansi/introduction/introduction.aspx?menuid=1](http://www.ansi.org/about_ansi/introduction/introduction.aspx?menuid=1)_
- NIST –Web Technologies – Systems Test Tools: _[http://xw2k.sdct.itl.nist.gov/brady/xml/index.asp](http://xw2k.sdct.itl.nist.gov/brady/xml/index.asp)_

**Notes:**
Optimize Technology
Future Preparation
Multi-pronged
Federal eRA

## Validation of File Submission and Receipt

- Senders file received, accepted, logged
- Transmission of receipt to sender
- Communications method should reduce email
- Proposal lock-down at submission
- Header records linking sender to recipient
- Validation turn-around time
- Factor in system-to-system accountability rules

**Notes:**
Optimize Technology
Future Preparation
Multi-pronged
Federal eRA

## Security Channel: Fully Defined 

- System-to-System authentication
- Access controls defined
- Encrypted credentials via standards
- Utilized for all communication
- Single sender digital certificate at institutional level
- Standardized header record for reconciliation

**Notes:**
Optimize Technology
Future Preparation
Multi-pronged
Federal eRA

## Grants.gov role:Pass-Through or Authoritative 

- Clarification of Grants.gov role
- Will all system-to-system (to/from) pass through Grants.gov?
- Will Grants.gov serve as a middleware channel?
- Will Grants.gov perform Authoritative functions?  Logging Activity  Problem Resolution  Access Rules Management

**Notes:**
Optimize Technology
Future Preparation
Multi-pronged
Federal eRA

## Proposal Lock-Down Functionality like CGAP? 

- Sender system proposal lock-down
- Date/time stamp generation from recipient system
- Ticket number for post file transmission
- Determine time of validation: Like US Mail or Grants.gov or Agency?

**Notes:**
Optimize Technology
Future Preparation
Multi-pronged
Federal eRA

## Redundant and Scalablewith 99.999% Uptime

- Supports high volume of transactions from large institutional senders
- Redundant capabilities for fail-safe functionality
- Scalable for supporting volume intensive submission deadlines by Agencies
- Agency policies agree to Point-Of-Failure (POF) delays of proposal submission:@Institution, Grants.gov or Agency POF
- Recipient system support for failed submission retry by automated or non-automated means

**Notes:**
Optimize Technology
Future Preparation
Multi-pronged
Federal eRA

## Fully Defined SDLC Change Control Process

- Formal change control processes
- Defined system-to-system application release schedule
- Requirements definition updates for feeder systems
- Comprehensive unit testing, regression testing, and user acceptance testing

**Notes:**
Optimize Technology
Future Preparation
Multi-pronged
Federal eRA

## Conclusion

- Standardize Data Sets
- Industry Standards
- Validation rules
- Security Channel
- Grants.gov role(s)
- CGAP like functionality?
- Redundant and Scalable
- SDLC Methodology

**Notes:**
Meet ERA expectations
Electronic requirements
Campus wide participation
Ongoing maintenance of ~$828K needed 

## 
Stephen Dowdy

**Stephen Dowdy**

## Coeus®

- 95 Licenses Granted
- Oracle
- SAP
- Currently Supporting version 2.2 to 3.8 plus pre-release of version 4.0

## Coeus v3.8

**Development**

**Coeus v3.8**

## Coeus v3.8

**Development**

**Coeus v3.8**

**EDI 194**

**XML**

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Coeus v3.8**

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Coeus v3.8**

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Coeus v3.8**

*Negotiations*

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Awards**

**Coeus v3.8**

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Awards**

**Coeus v3.8**

**EDI 850**

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Awards**

**Coeus v3.8**

*Subcontracts*

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Awards**

**Coeus v3.8**

*Conflict of Interest*

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Awards**

**Coeus v3.8**

**Powerbuilder**

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Awards**

**Coeus v3.8**

- SAP
- Other
- Financial
- Systems

***Data Warehouse***

*External Systems*

## Coeus v3.8

**Development**

**Institute**
**Proposal**

**Awards**

**Coeus v3.8**

**SAP**

**Data Warehouse**

***External Systems***

**Campus**

## Coeus pre-v4.0

**Development**

**Institute**
**Proposal**

**Awards**

**IRB**
**Human Subjects**

**Coeus pre-v4.0**

## Coeus pre-v4.0

**Development**

**Institute**
**Proposal**

**Awards**

**IRB**
**Human Subjects**

**Coeus pre-v4.0**

**Java**

## Coeus pre-v4.0

**Proposal**

**Awards**

**Proposal**
**Development**

**IRB**
**Human Subjects**

**Coeus pre-v4.0**

**Java**

## Coeus v4.0

**Development**

**Institute**
**Proposal**

**Awards**

**IRB**
**Human Subjects**

**Coeus v4.0**

**Java**

*MAY 2004*

## Coeus Architecture 

## Technology

- Java J2SE 1.4.2
- Server and Client
- Java Swing 1.1
- Client Application
- Java Servlet 2.3
- Server-side Application

## Technology (continued)

- XML
- JAXP-SAX 1.2 parser API
- Included in JDK
- JAXB
- Binds XML Schema to Java classes/objects
- FOP - formatted objects processor
- Apache project
- PDF generator
- iText
- Post PDF processing

## FOP

## Database Server

- Oracle 8.1.7 and 9i
- JDBC 2.0, OCI drivers
- SQL*Net with ANO

## Middle Tier

- Apache 1.3.26
- Web Server
- SSL Enabled
- Jakarta-Tomcat 4.0
- Application Server

## Tools

- SunOne
- IDE for Java development both client and server side application
- XMLSpy Enterprise Edition
- Schema design and management
- Style Sheet Designer
- Generates XSL-fo files using FOP
- PDF previewer

## Creating XML Datastream

- Grant application stream based on NIH Schema
- Compile NIH Schema with JAXB to produce Java classes
- MIT custom code populates these objects with data from the Coeus database producing a byte stream
- For printing, byte stream is sent to FOP for generating the PDF
- For data transfer, can be saved as XML file or incorporated into a SOAP message

## XSD Schema

- Binding File

- JAXB
- (xjc compiler)

- PI class

- Budget class

- Core class

- Database

- Java Class (xmlGenerate)
- Instantiate necessary classes (e.g., budget class).
- Call stored procedures to get data from database.
- Call setter methods in classes.
- Call JAXB methods to generate XML

- XML stream

- FOP

- XSL

**PDF**

## Coeus

**web.mit.edu/osp/www**
**coeus.mit.edu**
**Coeus-help@mit.edu**

## Coeus

***Questions?***

## Applicant S2S Alternatives

*Applicant S2S Alternatives*

- Vincent McCullough and Mike Atassi

## Introduction

- Our goal is to develop a standards-based interface using industry leading practices
- Objective is to be adaptive to changes driven by legislation and agency specific requirements
- Each agency may require unique forms for its opportunities
- Grants.gov must comply
- Challenge is to manage the the burden on the applicant system that result from these changes
- We are on the bleeding edge of technology
- Few if any systems must deal with this variability in submission content requirements
- While we have some thoughts on how to approach this problem, nothing is set in stone
- We are looking for feedback and/or recommendations

## Agenda

- Agency Web Services Background
- Applicant S2S Alternatives
- Next Steps

## Background – Agency Web Services

- Grants.gov has implemented a web services interface to support S2S interfaces to agency systems using
- Certificate based mutual authentication
- SOAP with Attachments exchange format

## Agency Web Services

- Current services include
- getApplicationList – Returns a list of applications received by the system.  Service includes ability to filter on processing status (e.g., received, validated, rejected with error)
- getApplication – Returns a selected grant application.  The application is returned as an XML document in the SOAP payload.   Attachments to the application are returned as SOAP attachments in the same form in which they were submitted
- getApplicationZIP – Returns the selected grant application as a ZIP file containing the XML, binary attachments, and PDF versions of the form data
- confirmApplicationDelivery – Allows agency to confirm that they have successfully received an application
- assignAgencyTrackingNumber – Allows an agency to assign agency tracking numbers to applications

## Preparations for Applicant Web Services

- As Grants.gov has been developed, we have done some preparatory work for supporting the Applicant S2S interface
- As each opportunity is defined in the system, and “opportunity schema”
- Defines required and optional forms that must be included
- Form schemas are included by reference in the opportunity schema
- Basis for construction grant application XML to be delivered to agencies
- All schemas (including opportunity schemas) are published and available for download on by Grants.gov users
- Grants.gov registry also makes instructions, PureEdge application packages available

## Sample Opportunity Schema

- See Separate Handout

## Sample Form Schema – SF424

- See Separate Handout

## Current Thinking on Applicant S2S Approach

- Employ ebXML compliant interfaces
- Establish Trading Partner Agreements
- Provide web services for automatically accessing our online registry of schemas and instructions
- Provide web services for submission and retrieval of processing status and validation error information
- Employ mutual certificate based authentication between applicant servers and Grants.gov

## Current Thinking on Applicant S2S Approach (cont.)

- Delegate responsibility to applicant system for verifying AOR authority to submit application
- Employ SOAP plus Attachments
- Initial use of “push” method for submission
- Current architecture expandable to support increases in volume
- However, “ticket” approach for managing volume peaks could be considered

## Application Submission Format

- Grants.gov has been speculating on what issues applicant systems might have with regard to preparing applications for submission
- Does applicant system support all of the forms required for a particular opportunity?
- Each agency has the ability to require unique forms for it’s grant applications
- Grants.gov must comply
- If not, how do we address forms that are *not* supported?
- Can applicant add forms and generate corresponding XML easily?
- Should/can Grants.gov provide alternate filing formats?

## Applicant S2S Alternatives

- Publish Form Schemas well in advance of opportunity publication
- Provide applicant systems time to implement required database and code changes
- Applicant system then constructs XML based on dynamically published opportunity schemas
- Development burden on Applicant System to implement agency specific forms and related database changes
- Fill PureEdge Forms From Applicant system
- Applicant system generates XML file
- PureEdge Viewer used to pre-fill PureEdge Package from XML file
- Remaining data elements completed through PureEdge package. Submitted via person-to-system interface
- Submit a mixture of XML and PureEdge forms
- Compare Opportunity Schema to list of supported form types
- Download individual PureEdge Forms for unsupported  forms.
- Prepare unsupported forms using PureEdge viewer
- Submit unsupported forms as attachments via S2S interface.

## Questions