REQUEST FOR PROPOSAL
Next Generation Solution to replace
Current STEVE Software Application
National Association for Public Health Statistics and Information Systems
962 Wayne Ave, Suite 701
Silver Spring, MD 20910
January 5, 2016
Table of Contents
INTRODUCTION/EXECUTIVE SUMMARY ... 3
ORGANIZATIONAL OVERVIEW ... 4
REQUST FOR PROPOSAL PROCESS AND PROJECT TIMELINE………..…………...6
ANALYSIS OF STRENGTHS AND WEAKNESSES………..…….16
MINIMUM FUNCTIONAL AND OPERATIONAL REQUIREMENTS……….…17
The National Association for Public Health Statistics and Information Systems (NAPHSIS) is seeking competitive bids from consulting firms and/or software vendors to develop and deliver a software solution to replace the current State and Territorial Exchange of Vital Events (STEVE) software application (functionality described below). For purposes of this request, the new functional software application/solution will be referred to as the
Proposed Solution and/or New Solution. Respondents may propose proprietary and/or open source technologies but are encouraged to consider creative solutions that facilitate flexible, adaptable and nimble deployments. The selected vendor will be expected to produce a solution to be deployed in cloud computing based environment such as the APHL INFORMATICS MESSAGING SYSTEM (AIMS) and/or the PUBLIC HEALTH COMMUNITY PLATFORM (PHCP) both of which are public health focused adaptions and configurations of the Amazon Web Services cloud solution.
The PROPOSED SOLUTION will be utilized across the US State and Territorial public health community to exchange vital events notifications. The solution is expected to be
developed and deployed in a series of iterative cycles to facilitate the needs of the public health vital statistics community and available funding. The respondent should propose firm quotes for phases 1 and 2 as described below and provide quotes for annualized technical support and optional hosting for subsequent years. The resulting solution will be considered a “work for hire” and full title will reside with NAPHSIS. Any exceptions to this stipulation or commercial off the shelf products (COTS) incorporated into the proposed solution must be clearly identified and justified in the technical proposal. Sample technical support contracts and annualized technical support cost estimates must be included for any COTS products incorporated. Any custom code or configuration
developed with funds supplied by NAPHSIS will become the sole property of NAPHSIS and the vendor shall provide a release of all claims to said code and/or configurations.
NAPHSIS intends to pursue a contract with the successful bidder. However, such pursuit is contingent on and subject to the availability and appropriation of funds from federal and/or other sources as well as NAPHSIS business requirements and priorities. Bidders should be aware that the potential mix of federal and/or other public funds utilized for this project could subject the proposed solution, including technical and operational details to classification as public domain and/or subject to freedom of information requests.
No liability or obligation for payment will develop between the parties until an appropriate agreement has been approved by NAPHSIS. The continuation of the contract in
subsequent years is similarly contingent.
Exiting business and technology requirements demand an accelerated timeline with Phase 1 production deployment not later than September 30, 2016. Public health participants should complete their transition to the new solution by December 31, 2016.
NAPHSIS and its members work with a variety of partners to improve the efficiency and security of vital records operations in every state, plus the District of Columbia, New York City, Puerto Rico, Guam, American Samoa, the U.S. Virgin Islands, and the Northern Marianas Islands. Working with federal partners such as CDC, NCHS, the Social Security Administration, the Department of State, the Department of Homeland Security, and the Office of Personnel Management, NAPHSIS has developed and operates electronic systems for vital records offices that:
• Allow for the secure exchange of vital records and information among
• Provide data to agencies that use information from birth and death records, and • Support electronic verification and/or certification of vital event records.
NAPHSIS supports these initiatives to improve the quality, speed, availability, and security of vital records and statistics through training, standards, best practices, and technical assistance.
NAPHSIS also works with its members, its corporate partners, and NCHS to support the development and use of electronic birth and death registration systems. These systems enable health departments in general, and vital records agencies in particular, to register and administer vital records securely, accurately, and quickly. Chances are, if you order a certified birth or death certificate, it will be issued from one of these systems.
Accurate and timely records of birth and death are essential to various industries within and external to public health. Public Health surveillance, outreach and intervention particularly require vital record data. Newborn screening and immunization programs require timely birth data to ensure all babies are screened for life threatening disorders and are fully immunized. Public health surveillance on chronic and infectious diseases require coded and timely death data to monitor cause of death rates across the population. Death data is used to determine areas of outreach for public health to decrease rates of preventable death. Vital records provide the baseline data for the population, which is then used as the denominator to all population rate calculations. STEVE is the cornerstone application that provides the ability to exchange vital record data across state and jurisdictional borders to fulfill these essential public health functions. In addition to public health, many other arenas require vital records data. The public entitlement programs such as Social Security, law enforcement, education, the insurance Industry, voter registration organizations, and research institutions are just a subset of industries that request vital record data. Rapid and precise reporting of birth and death to these agencies helps prevent fraud, assist in criminal investigation-including missing persons, and saves taxpayer money. To track citizens’ records across jurisdictions requires the robust vital record data exchange provided by STEVE.
Why is it so important to keep these records secure? Vital records contain sensitive crucial data that must be protected to prevent against fraud and identity theft. Birth certificates, for example, are used as a primary source to confirm a person's identity and citizenship. Death certificates contain information that is used to establish false identities and contain sensitive information. Jurisdictions have laws and regulations to protect these electronic records from fraudulent use and prevent identity theft. Access to your electronic record is limited to authorized public health and administrative uses.
Inter-Jurisdictional Exchange Committee and Agreements
To facilitate the efficient and consistent exchange of data, NAPHSIS established an Inter-Jurisdictional Exchange Committee, composed of NAPHSIS members and association staff. This committee has the responsibility of establishing and managing agreements with jurisdictions regarding vital events records. To that end, the committee established a structured agreement consisting of a main body with addenda. The main body of the agreement, known as an Inter-Jurisdictional Exchange Agreement, or IJE, contains generally accepted terms and conditions while the addenda include jurisdictional specific data use and exchange rules.
The IJE Committee has also established and maintains templates for format and data element requirements for several IJE message types as outlined elsewhere in this document.
These agreements will be integrated into the proposed solution as indicated below.
STEVE, 1st Generation (Existing Solution)
Births and deaths often occur away from a person's resident jurisdiction. Jurisdictions report public health statistics for all residents, and the federal government provides
statistics for the entire nation. For these reasons, vital records jurisdictions must be able to share data with one another, the National Center for Health Statistics, and other
authorized data partners.
To accomplish this important public health service, NAPHSIS developed the State and Territorial Exchange of Vital Events (STEVE) system. Using STEVE, vital records jurisdictions:
• Send statistical data to the National Center for Health Statistics for inclusion in the
National Vital Statistics System,
• Send vital records that pertain to residents in other jurisdictions so the home
jurisdiction's reports include these important data,
• Send death information to the jurisdiction of birth so that birth certificates can be
• Provide data to authorized data partners for use in authorized public health and
STEVE, in its current manifestation includes a Transformation Module (T M), which is installed and managed within the jurisdiction. The TM performs certain data
manipulations and communicates with a Controller Module (CM) which is hosted by the current software vendor. The CM manages the message routing and security processes as well as master user and role security.
Significant progress has been made in data exchange of vital events data with NCHS and between jurisdictions, through the current version of STEVE. However, considering the technological advances over the past several years, the needs of the user community, along with gaps in present technical architecture (including potential security
vulnerabilities because of technology obsolescence) NAPHSIS concluded that investing in the current STEVE model to enhance and extend its life is not a viable option. Key
stakeholders agree that NAPHSIS should design and build the “next generation” of STEVE to fulfill the current and future needs for the safe, timely and accurate exchange of vital records data. The next generation should eliminate or minimize locally installed
components, shifting transformation, configuration and routing to a cloud based system. Technology support and existing contracts require the solutions to be completed and ready for production utilization by September 30, 2016 to facilitate a 90 day transition period for public health participants.
REQUEST FOR PROPOSAL PROCESS AND PROJECT TIMELINE
NAPHSIS intends to pursue a contract with the successful bidder. However, such pursuit is contingent on and subject to the availability and appropriation of funds from federal and/or other sources as well as NAPHSIS business requirements and priorities. No liability or obligation for payment will develop between the parties until an appropriate agreement has been approved by NAPHSIS. The continuation of the contract in subsequent years is similarly contingent.
Respondents shall prepare all proposals and supplemental material at their own expense and shall not be reimbursed by NAPHSIS.
This RFP and all associated materials are the exclusive property of NAPHSIS and must not be disclosed or distributed by potential respondents except as required in the process of assimilating a project team and preparing responses.
All proposals and submitted materials become the exclusive property of NAPHSIS and will not be returned to bidders. NAPHSIS will take reasonable precautions to protect technical and financial details of proposals from disclosure outside the review and selection process to the extent possible. Specific confidential materials submitted as part of the proposal process must be clearly identified as such. However, bidders should be aware that the potential mix of federal and other public funds utilized for this project could require the
selected new solution, including technical and operational details, to become public domain and/or subject to freedom of information requests.
Deliverable Dates Due
NAPHSIS releases RFP January 6, 2016
Virtual Bidders Meeting (see call in info below) January 12, 2016 2 PM EST
Written Questions Due to NAPHSIS By Email:
swebster@NAPHSIS.org January 13, 2016 5 PM EST Response to Questions Distributed to Potential
Respondents January 15 2016 5 PM EST
Proposals due to NAPHSIS Office (5:00PM ET) preferred method of submission – email. [swebster@NAPHSIS.org]
February 1, 2016
Emails by 12 Midnight EST
Review of proposals February 1 – February 12,
Selection of Successful Bidder February 15, 2016
Contract Executed March 18, 2016
Solution Completed and Ready for Production September 30, 2016
INSTRUCTIONS FOR PARTICIPATION
Date: Tuesday, January 12th
Time: 2:00-3:30 pm Eastern Time
JOINING THE AUDIO
Audio Conference Phone Number: 415-655-0003
Access Code: 663 031 037
JOINING THE WEBINAR
Click Here to Join the Event
Event password: 1234
The virtual bidders meeting will include a web based functional demonstration of the existing technology and provide an opportunity for respondents to ask specific questions regarding the existing solution. All questions and verbal responses will be recorded and provided in writing along with responses to written questions.
NAPHSIS reserves the right to reject any and all proposals and nothing in the RFP shall be construed as an obligation by NAPHSIS to pursue a contracting option. Final selection of vendor will be at the sole discretion of NAPHSIS and decision to initiate contract
negotiations shall be subject to funding availability and other business needs of NAPHSIS.
Any appeal or objection to NAPHSIS selection of successful bidder must be filed in writing not more than 48 hours following announcement. Appeals should be addressed to: NAPHSIS
C/o Shawna Webster, Chief Operating Officer swebster@NAPHSIS.org
Appeals will be arbitrated by the NAPHSIS board of directors whose decisions shall be final.
Conformance to Business Requirements 10% Conformance to Technical Requirements 10% Proposed Development Timeline and Project
Plan for Phase 1 20%
Cost of Phase 1 20%
Proposed Development Timeline and Project
Plan for Phase 2 20%
Cost of Phase 2 5%
Overall Understanding of the Need and Project Management, Tracking and Reporting
5% Quality Assurance and Remediation Process 5% Past Performance and Client Satisfaction 5%
Proposal Format and Content
The response format is flexible and allows for vendors to suggest and/or propose alternative solutions and approaches to accomplish the overall functional and financial goals. However, NAPHSIS reserves the right to disregard material and suggestions it considers in its sole discretion to be non-responsive. While NAPHSIS understands the need to be thorough and complete in proposals, respondents should consider brevity a virtue. The suggested proposal content and length limits are as follows:
• Cover Letter, signed by an officer or individual with designated authority to obligate the bidder to contracts and should so indicate in the letter. The letter should also indicate the bidder is responsible for the contents of the bid and the bid is valid for a period of at least 180 days from submission date (One page).
• Table of Contents
• Company/Organization/Joint Venture/Partnership Introduction (Maximum of two pages, single spaced using 12 point font)
• Executive Summary of Proposed Solution (Maximum of 3 pages, single spaced using 12 point font. Images and diagrams may be included but shall not count toward the page limit)
• Detailed Description of the Proposed Solution (Maximum of 20 pages, single spaced using 12 point font. Images and diagrams may be included in this section but will not count toward page limit). Include description of documentation to be provided (potential examples of documentation include: architectural diagrams, functional and data flow diagrams, specifications, training documentation, configurations, etc.).
• Project Plan (Maximum of 15 pages using 12 point font including Charts and Tables) o Gantt chart view
o Additional tabular view of project steps
o Show process and steps to achieve Phase 1 product/project delivery by September 30, 2016
o Show process and steps to achieve Phase 2 product/project delivery and specify the anticipated delivery date
o Narrative discussion of project management approach
o Narrative discussion of quality assurance process and approach o Discussion of proposed testing and validation process
o Description of issues tracking and remediation process o Discuss post-delivery support process and proposed timeline
o Discuss training process for end users and public health jurisdiction local administrators
o Discuss training process for overall system/application administrators
• Cost proposal (Maximum of 3 pages using 12 point font)
o Fixed cost for solution development and deployment: Phase 1 o Fixed cost for solution Development and deployment Phase 2 o Training of jurisdiction end users
o Training of jurisdiction administrators
o Training of national system wide administrators o Optional – Proposal for hosting solution for year 1 o First year technical support
o First year application functional support
o Technical and functional support estimates for years 2 through 5
• Qualifications: Describe the bidder’s corporate experience in projects of similar scope. Propose key staff and indicate key qualifications to execute such a project.
• Discuss warranties provided by the vendor and terms and conditions of those warranties. Anticipated warranties include but are not limited to:
o General Indemnification
o General warranties (defects, material, workmanship and meeting specifications, etc.)
o Warranty against planned obsolescence o Warranty against infringements
o Warranty against encumbrances o Others as appropriate
• References: Provide at least three references for projects of similar scope. Include contact email and phone number.
• Appendices: Attached supplemental information which may be important in facilitating NAPHSIS timely and effective decision making process. Include sample software licensing agreements particularly for any commercial off the shelf or third party technology provided as part of the bidders overall proposed solution.
This request is for proposals to develop, deploy and support a fully functional, cloud based software application/solution to facilitate electronic messaging of vital records. The proposed solution will replace functionality currently existing within the STEVE application and be deployed in a phased rollout. Project scope is as follows:
• The existing STEVE application is scheduled to be fully de-commissioned by December 31, 2016.
• Phase 1: Bi-directional core messaging between jurisdictions and potential uni-Directional messaging to NCHS as specified in the Strategic Vision section (Phased Rollout) below
• Phase 2: Active bi-directional messaging with NCHS as specified in the Strategic Vision section (Phased Rollout) below
• Annual technical support for years 2 through 5
• Scope Limitations:
o NAPHSIS does NOT anticipate re-negotiating existing agreements. o NAPHSIS does NOT anticipate updating message formats.
o NAPHSIS does NOT anticipate changing business rules.
• Hosting: The solution is expected to be hosted in conjunction with the Public Health Community Platform on APHL’s AIMS Platform. As such, hosting costs are expected to be out of scope for this RFP. However, bidders are encouraged to include optional estimates for annual hosting in a cloud environment. Estimates should be provided for year 1 (6 months development only, 6 months development and production environments) and for both production and test environments for years 2 through 5. If such estimates are provided, be cognizant that the selected new solution will actively exchange personal identifiable information.
STRATEGIC VISION AND PROJECT APPROACH
The successful bidder will provide a technology solution to replace the aging STEVE software application. In addition, the proposed solution should support functional expansion to meet the evolving needs of the public health vital statistics community. Bidders are free to propose alternative solutions which may expand the functional
footprint and better serve the long term operational efficiency of nationwide vital statistic data exchange. As it exists today, NAPHSIS envisions that the proposed solution will employ the following strategies:
• Personal Health Information: The proposed solution will contain personal identifiable health information. As such, the proposed solution MUST meet
requirements of the Health Insurance Portability and Accountability Act (HIPAA) as well as modern and evolving cyber security regulations (i.e. FISMA, FedRAMP, NIST, etc.).
• System Administration: It is envisioned that access to the system would be role based, and provide for multiple layers of system administration. A senior or national level administrator would be responsible for enrolling and authorizing jurisdictions onto the system. The local or jurisdictional administrator would be responsible for adding local users, designating those users level of data access and creating local business rules for sending and receiving data with trading partners. Administration will be performed through a user interface presentation layer.
• Operational Deployment: The proposed solution is expected to be fully cloud based with little or no jurisdictional footprint. Jurisdictions will extract and prepare compliant files containing IJE defined content and transmit those files to the cloud based solution through an automated back end process or manually by logging in to a user interface presentation layer or portal. The application will apply pre-defined business rules to ascertain the intended receiving jurisdiction and transform
messages to contain only those data fields authorized for distribution to the receiving jurisdiction.
• Cloud based infrastructure and software platform services: Adopting cloud based (third party hosted shared services with predefined service and operational level agreements) infrastructure and software platforms that are Public Health focused, will offer the needed flexibility and scalability while eliminating (or at least
significantly reducing) the technical footprint within the jurisdiction. This reduces the number of jurisdiction IT system/staff problems experienced by vital records agency personnel, especially in terms of troubleshooting system outages. A cloud based system would be less resource-heavy on the jurisdiction side as well, both in terms of server space and personnel time. APHL’s AIMS platform, is an example of this offering, as is the AWS (Amazon Cloud) and Microsoft’s Azure.
• Modular and Service Oriented Architecture (SOA): The proposed solution and technical architecture should align to modular and service oriented architecture paradigms. This means designing and implementing each discrete function or capability in this data exchange solution as a modular software service. This will result in quicker deployment and adoption of the capability, while positioning for phased rollout of improvements and enhancements. This approach will allow NAPHSIS to focus on the core messaging functionality first, building trust and faith in the new system while funding and adding other enhancements and services as funds become available.
• High Level Services Anticipated in the Solution:
o Business rules (filtering) service
o Intelligent routing (deriving destinations) service o Cryptographic (encryption/decryption) service
• NAPHSIS envisions that one or more Integration engines would be essential components of the technical architecture. These are software platforms built for enabling data exchange scenarios and come with built-in configurable infrastructure and solution frameworks and are widely used in other Public Health data flow scenarios. These tools should be considered as part of the technical architecture.
• The SOA paradigm also offers opportunities to streamline process flow leading to optimal operations and higher quality of data. Offering NCHS’s cause of death coding capability as a service is an example of such streamlining efforts. It reduces the duplicate data exchanges while improving the data quality and providing new mechanisms to handle exceptions. Cause of death coding currently utilizes the International Classification of Diseases (ICD 10) code set.
• The proposed solution should consider opportunities to automate current manual and semi-automated processes that provision data from and consume data into operational vital record systems (electronic birth registering system, EBRS and electronic death registering systems, EDRS). This will make adoption time frames shorter and reduce the operational burden on jurisdictional staff.
• Jurisdictional Vital Records Offices routinely provide vital records information to a wide variety of public, semi-private and private organizations. It is imperative to make this data available to such audience in a reliable, timely, convenient and cost effective manner making it a valuable service for data consumers while in
compliance with the sending jurisdiction’s data sharing policies and procedures and without burdening the staff at jurisdictions to full fill these needs.
• Phased rollout: NAPHSIS envisions a phased deployment model. Phase 1 would include bi-directional core messaging (Birth, Death, Fetal Death, Birth Infant Death, Death Roster and Induced Termination of Pregnancy (ITOP) reporting) utilizing the IJE format defined content (see accompanying spreadsheets) between jurisdictions. Core messaging includes the ability to validate uploaded messages, creation of human readable and understandable error messages and creation and delivery of message acknowledgements. Multiple transport mechanisms (VPN, PHINMS, FHIR, Direct, etc.) and multiple technical formats (HL7, XML, FHIR, CSV, etc.) should be supported. Phase 1 should also include the ability to send data files to CDC’s NCHS. Delivery methodology for NCHS will be negotiated subsequent to contract
execution, but could include sending to a PHINMS endpoint inside or outside of CDC’s DMZ, or placing such files in a specified temporary cloud storage (folder) for retrieval by CDC on demand. In general, message routing is expected to be “real time.” Phase 2 includes active bi-directional messaging with CDC’s NCHS which may require the solution be subjected to CDC’s certification and accreditation process. Additional future phases will be prioritized by the public health vital statistics
community but will generally include messaging with other specified trading partners.
• Illustrations of data flows and stakeholders:
STEVE (State and Territorial Exchange of Vital Events) is the software application that currently enables electronic data exchange of vital events. The illustration below depicts the current data flows across the stakeholders. STEVE has been deployed at a majority of the 57 jurisdictions.
• Conceptual Architectural Diagram (concept for illustration only. Bidders should
consider and develop their own approaches).
ANALYSIS OF STRENGTHS AND GAPS OF CURRENT STEVE SOLUTION. • Strengths
o STEVE provides fundamental data exchange capabilities across different stakeholders in this domain. It is considered as ‘one stop shop’ fulfilling the exchange of vital records data.
o STEVE uses a defined, agreed-upon format, the Interjurisdictional Exchange (IJE), for syntax and semantics, aligning with interoperability principles. o STEVE supports data sharing agreements and governance mechanisms. o STEVE is deployed in nearly all of the jurisdictions.
o STEVE is “route not read” and therefore does not need to accommodate the rules and technology needed to safeguard “held” sensitive data.
o STEVE has a tightly coupled architecture which requires an all-or-nothing upgrade and refresh model, leaving no room for incremental improvements and enhancements.
o STEVE relies heavily on software components that are deployed locally within each jurisdiction. This requires a reliance on each jurisdiction’s IT department for operations support and makes troubleshooting time-consuming for all parties.
o STEVE’s underlying technology is becoming obsolete and the components of STEVE’s technology architecture are past their end-of-life support.
o As a result of STEVE’s technology obsolescence, information and system security risks become a concern.
o STEVE relies on manual or semi-automated pre and post processes to perform data exchange. For example:
• Pre-process manual user intervention
1. File generation and compilation to IJE format 2. File naming to the agreed conventions and 3. File upload
• Post process manual user intervention
1. File downloads
2. Convert to receiving system(s) format 3. Validate and upload into receiving system(s)
o The constant certificate upgrade process is burdensome. Longer cycles for certification and/or production mode usage may decrease support calls.
o STEVE lacks bi-directional capability with NCHS resulting in a less than optimal partnership. NCHS can receive data through STEVE, but cannot feed updated/corrected/coded vital events data back to jurisdictions through the same system.
o STEVE has file size limitations, through PHINMS transport, that require large files to be divided and sent piecemeal to NCHS (‘chunking’).
MINIMUM FUNCTIONAL AND OPERATIONAL REQUIREMENTS
• The proposed solution should be able to securely send and receive IJE files, files containing IJE defined content (see accompanying spreadsheets) and coded files – both between jurisdictions, from jurisdictions to NCHS, and from NCHS back to the jurisdictions.
• The proposed solution must Support Interjurisdictional Exchange (IJE) format defined content for all messages submitted to and routed through the Proposed Solution/application. NAPHSIS’s Interjurisdictional Exchange (IJE) Committee has defined data elements for exchanging vital event information. Files have been defined for the following file types:
o Natality (birth) o Mortality (death)
o Roster (short-form death) o Fetal Death (stillbirth) o Birth Infant Death o ITOP (induced abortion).
• The proposed solution must have the ability to route vital records data to a jurisdiction based on applicable and configurable business rules.
• The proposed solution must have the ability to route coded cause of death data and bridged race codes to the jurisdictions (as well as to NCHS if coded by the
• The proposed solution must incorporate the IJE agreements as digital assets that include metadata that can be used to automate system configuration to the greatest extent possible.
• Data elements authorized and/or required by IJE agreements should be visualizable in the presentation layer and administration function.
• The proposed solution must have the ability to create and perform custom routing of vital records data to other approved data users (message configuration portal).
• The proposed solution must have user interfaces for configuring parameters for data exchange for those items that cannot be configured automatically.
o All user interfaces in the proposed solution must be intuitive and easy to use. For example, when setting up a filter, it may be easier to copy an existing filter, and make minor changes to it rather than creating a filter from scratch.
o The ability to define unique mailboxes for any given data exchange partner must be efficient and intuitive for the user.
o It is highly desirable for the proposed solution to have the ability to fully automate the exchange without user involvement.
o It is highly desirable for the proposed solution to have the ability to manage and schedule each data exchange independently.
• The proposed solution must have the ability to audit changes to the user profiles, jurisdictions data filters, as well as other user defined actions. Such auditing should include at a minimum the date/time of creation and any edits and should identify the user making the change.
• The proposed solution must allow both batch transmissions AND exchange on a record-by-record basis (business process triggers).
• The proposed solution must have the ability to produce understandable and actionable error messages.
• The proposed solution will have the ability to perform validation on the file being exchanged and apply business rules on the completeness and validity of the data. Master validation rules should be editable and modifiable by national level administrators.
• The proposed solution will have the ability to create and report summaries of vital record data without data being stored in any central location. It should also include metadata to automate system configurations. These reports should be easily produced and customizable. Included in the reports would be sender
configurations that the receiver can access.
• Trading Partners (“mailbox” functionality): The proposed solution must allow a jurisdiction to easily create a profile for trading partners. It must capture any information needed to establish, maintain and update filters that will be used to determine the secure data exchanged between each partner. Before the exchange of data takes place, the data will be filtered to remove data that cannot be
exchanged as stated in the trading partner agreements.
• The proposed solution must have the ability to provide metrics for its use (i.e. how many messages sent per day to a partner).
• CAUSE OF DEATH CODING: Automated cause of death coding is not anticipated in the first phase of development for the Proposed Solution. Jurisdictions send messages with cause of death in plain language. When automatic cause of death coding is not available, the proposed solution will send the records to NCHS for manual coding. When a record is sent to NCHS for manual coding, the jurisdiction must get an alert that the record needs manual coding. Cause of death coding utilizes International Classification of Diseases (ICD 10) code sets.
• Respondent organizations and/or the proposed solution must have a support infrastructure including but not limited to:
o Manual & active help link features o Method for submitting change requests o Training
o Change logs
o Role based user group management and methodology for integrating existing STEVE user groups. Formal change management process. *The system should enable a jurisdiction to initiate a help desk ticket from inside the proposed solution/application as well as by sending an email or calling a toll-free number. The support staff shall provide active support during the hours of 8 until 5 Eastern Standard Time.
• The Proposed Solution must have the ability to increase the scale of the software to include additional data exchange partners. Scalability should be controlled through the UI and not with additional development.
• The Proposed Solution must have the ability to diagnose and collect diagnostic information on network performance and availability.
• The proposed solution must support interoperability using national standards for healthcare data exchange. This requirement is intended to support growth in our data exchange networks and partners which could include healthcare providers, hospitals, medical records vendors, Federal and State agencies and other public and private entities. Supported standards should include but are not limited to:
o Data Formats:
IJE defined content as defined elsewhere in this document and specified in the accompanying spreadsheets.
Health Level 7 (HL7)
Integrating the Healthcare Enterprise (IHE) Fast Healthcare Interoperability Resources (FHIR)
o Transport protocols: Data transport is required to be secure and reliable It is also expected to be payload (content) agnostic, meaning that the transport can move types of data (Natality vs Fatality) and/or formats of data (IJE vs HL7). Data transport should also be decoupled from the use case logic. The capabilities presented by CDC’s PHINMS team and APHL’s AIMS platform supports this model and offers options and alternatives. PHINMS (developed by CDC, this protocol has been a longstanding
standard of the public health domain. Other protocols must be supported due to limitations of this protocol and planned obsolescence and redevelopment over the next few years). Web Services
Virtual Private Network (VPN)
Secure File Transport Protocol (SFTP) DIRECT TRUST (Optional)
o Terminology Standards: The system must continue to support medical-coding requirements as defined by the National Center for Health Statistics.
Additionally, the system should use nationally accepted terminology standards wherever possible including but not limited to:
Federal Information Processing Standard (FIPS) International Organization for Standardization (ISO) International Classification of Diseases (ICD 10) • Security Requirements
o The system will be used in multiple organizations that cover federal, state and local security and privacy laws, policies and regulations. We believe that most organizations, while having certain specific requirements, should essentially conform to federal requirements and standards. Therefore, the following federal standards shall be considered absolute minimum
requirements for the Proposed Solution.
Health Insurance Portability and Accountability Act (HIPAA) –Includes minimum requirements for personal identifiable data protection across the national healthcare landscape.
Security controls and assurance requirements as described in NIST Special Publication SP 800-53 Rev 4, "Recommended Security Controls for Federal Information Systems."
FISMA FIPS 200, “Minimum Security Requirements for Federal Information and Information Systems.”
Phase 2 may require authorization through CDC’s Certification and Accreditation (C&A) process that includes:
• A formal process working with CDC’s Office of the Chief Information Security Officer (OCISO) to obtain an Authorization to Operate (ATO).
• A current Privacy Impact Assessment (PIA)
• Vulnerability assessment (VA) scans performed by CDC’s Information Technology Services Office
Additional security requirements applied to cloud-hosted solutions and platforms include:
• FedRAMP - https://www.fedramp.gov/
• Federal Information Security Modernization Act (FISMA) Compliant (Moderate level at a minimum) -
• Compliance Requirements: In addition to security and functional requirements specified elsewhere, the proposed solution must comply with section 508 of the Rehabilitation Act of 1973. (Section 508 Electronic and Information Technology Accessibility Standards).
• Multiple Environments: The successful bidder shall maintain a test/development environment for the duration of the project and contract period. A production environment must the installed, operational, tested and verified as reliable, functional and scalable by anticipated go live date (September 30, 2016) and
maintained for the duration of the contract period.
FUTURE FUNCTIONALITY: COULD BE ADDITIONAL MODULES TO THE PROPOSED SOLUTION, OR INDEPENDENT APPLICATIONS WITH WHICH THE PROPOSED SOLUTION WILL INTERACT.
This section outlines desired or optimal functionality which may not be immediately available within the currently funded project. However, bidders should be aware of the future desired functionality and provide an infrastructure solution which can be improved by incorporating such additional “modules” without a complete redevelopment of the core application and/or be able to integrate with such external functional applications through a simple application interface.
• Cause of Death Coding: Future functionality will include the ability to perform automatic cause of death coding when applicable. Jurisdictions send messages with cause of death in plain language. Automatic cause of death coding WOULD
TRANSLATE SUCH PLAIN LANGUAGE TO CODED DATA FOR TRANSMISSION TO APPROPRIATE TRADING PARTNERS. When cause of death coding is not
immediately available, the proposed solution will send the records to NCHS for manual coding. Cause of death coding utilizes International Classification of Diseases (ICD 10) code sets. THIS FUNCTIONALITY WOULD ALSO PROVIDE A SEARCHABLE TABLE OR SIMILAR FUNCTIONALITY FOR SEARCHING AND APPLYING APPROPRIATE CODES BASED ON CODES AND/OR DESCRIPTIONS. Cause of death coding as a service residing within the proposed solution could be used by
jurisdictional nosologists to streamline workflow by ensuring IJE’s will have coded values from the onset and could eliminate the current duplicate processing between Jurisdictions and NCHS.
• Future phases of Proposed Solution should extend its reach so that there is the possibility of exchanging data with other Electronic Birth Registration Systems (EBRS) and Electronic Death Registration Systems (EDRS).
• The new system could automate data flow into and out of other vital records operational systems (i.e., EBRS and EDRS). This level of automation could be achieved by developing software interfaces which provide clearly defined operations and functions which can be called by an EDRS or EBRS. These interfaces, packaged as an adapter, would enable system-to-system interaction and greater automation.
• Standard interfaces in the context of vital events could be birth record data extraction from an EBRS(example: getNatality), and the data loading and consumption back into the EBRS (example: setNatality). The same process may be used for death record data with the extraction and loading of fatality data in an EDRS (Example getFatality and setFatality). This approach could lay the foundation for Fast Healthcare Interoperability Resources (FHIR) architectural paradigm implementation.
• The next generation proposed solution should consider expanding its market across a wider variety of public, semi-private and private organizations which might
benefit from having more timely data. Potential agencies and organizations such as the Social Security Administration, Law enforcement, Education, National Weather Service, Voter registration, Transportation, Internal Revenue Service, and Research institutions are just a subset of industries that currently request subsets of vital record data.