Transitional GIS Data Requirements Sample Clauses

Transitional GIS Data Requirements. Version 2.0 (2017) 1 Summary The following geospatial data and corresponding attribute specifications are required to be regularly maintained by each county for Mapped Automated Location Information (ALI), Location Validation Function (LVF) and Emergency Call Routing Function (ECRF). This document is referenced in the Capital Area Emergency Communications District Interlocal Contract for Geographic Information System Data and the Capital Area Emergency Communications District Interlocal Contract for Next Generation 9-1-1 Database Program documents and is commonly called “Attachment B Requirements”. The GIS Data requirements in this document are a condensed version of, and based upon, NENA (National Emergency Number Association) standards as they are developed and evolve over time. We are in a lengthy transitional period to Next Generation 9-1-1 (NG9-1-1). Data model standards should be more thoroughly reviewed in the “NENA Standard for NG9-1-1 GIS Data Model” document. Specifics regarding address point placement methodologies should be reviewed in the “NENA Information Document for Development of Site/Structure Address Point GIS Data for 9-1-1” document. There are other useful resources, as well, and CAPCOG will provide several of these on its own Web Site. Please provide monthly updates of the 9-1-1 datasets referenced in this document in ESRI file geodatabase format by the 1st business day of each month. Incomplete datasets or other data abnormalities related to requirements may be returned to the county for correction. To be included in that month’s PSAP update, the data must be returned to CAPCOG by the 5th business day of that month. Regarding database fields and data types, each is very specific and must follow the exact guidelines outlined below. For example, the “L_ESN” field must be Text type with a character width of 5. Remember to keep the field names in your database the same as those listed, and in the same order, and that all entries for every field must be in UPPER CASE. The complete attribute definitions shown in the GIS data tables are described and defined in the “Database Format” sections for each dataset. The data fields shown as Mandatory and Conditional must be present in the data. In the tables below, the column M/C/O is to indicate whether the attribute values is Mandatory (M), Conditional (C), or Optional (O). • Mandatory signifies an attribute value must exist • Conditional signifies that if the attribute information exists in the...
Sample 1Sample 2Sample 3
AutoNDA by SimpleDocs
Transitional GIS Data Requirements. Attachment B. This document describes the technical requirements and expectations for GIS data maintenance and monthly submissions.
Sample 1Sample 2Sample 3
Transitional GIS Data Requirements. C. Jurisdictional Polygon
Sample 1Sample 2
Transitional GIS Data Requirements. 14.5. This contract is binding on and inures to the benefit of the parties' successors in interest and may not be assigned without the express written permission of CAECD.
Sample 1Sample 2
Transitional GIS Data Requirements describes a “LAST_MOD” or Last Modified date field in each of the GIS data layers and is marked as mandatory for completion. In order for CAPOG to begin tracking what is ‘new’ data and what is ‘legacy’ data, we need this field to be completed in each of the data layers. Our goal in differentiating between these two datatypes is so that we can determine if progress is being made in data error correction. Use of this field willalso be monitored and included in the performance reports that CAPCOG will send out each month. If there is a GIS feature that was created prior to October 1, 2019 and the LAST_MOD field is NULL or otherwise not known, this field should be populate with a date of 10/1/2019 and will be counted as legacy xxxx.Xxx way to have this field updated automatically when editing or creating features is to use‘editor tracking’ on the feature class. This can be done by right‐clicking the feature class in ArcCatalog and then selecting ‘Properties’. When the Feature Class Properties dialog box opens, select the ‘Editor Tracking’ tab. The below image shows how this can be set up: • Check the ‘Enable editor tracking’ box • Set the ‘Edit Date Field’ to LAST_MOD • Select ‘Database Time’ to record dates New Quality‐Control (QC) Platforms: The Capital Area Emergency Communications District (CAECD) has purchased two all‐new quality‐controlsystems for our counties to use. These will be used as a means to not only quality control GIS data and return the results of errors but, in the case of the Enterprise Geospatial Database Management System (EGDMS), will actually provide data to the functional elements of a NG9‐1‐1 environment. Again, in NG9‐1‐1, GIS data is the driver of call routing! Enterprise Geospatial Database Management System (EGDMS) Vendors: AT&T and Intrado The Enterprise Geospatial Database Management System (EGDMS) is a web application that serves as the front‐end user interface for the NENA Spatial Interface (SI)requirement. GIS data submitted through EGDMS is validated, coalesced, and used for provisioning to NG9‐1‐1 (sometimes referred to as i3) systems which are called the ECRF and LVF. Thesestand for Emergency Call Routing Function and the Location Validation Function. Both of these elements are major components in the NG9‐1‐1 environment One of the biggest advantages in moving to this system is that it will enable counties the ability toupdate PSAP map data much more frequently than our current workflow of just once a month. EGDMS includes...
Sample 1
Transitional GIS Data Requirements. Version 2.0 3 (20172021) 1 Summary The following geospatial data and corresponding attribute specifications are required to be regularly maintained by each county for Mapped Automated Location Information (ALI) and use in a Next Generation 9-1-1 system which relies on GIS for call and dispatch routing through the ), Location Validation Function (LVF) and Emergency Call Routing Function (ECRF). This document is referenced in the Capital Area Council of Governments Interlocal Agreement for 9-1-1 Geographic Information System Database Management Capital Area Emergency Communications District Interlocal Contractfor Geographic Information System Data and the Capital Area Emergency Communications District Interlocal Contract for Next Generation 9-1-1 Database Program documents and is commonly called “Attachment B Requirements”. The GIS Data requirements in this document are a condensed version of, and based upon, data standards created by NENA (National Emergency Number Association) standards as they are developed and evolve over time. We are in a lengthy transitional period to Next Generation 9-1-1 (NG9-1- 1). These dData model standards should be more thoroughly reviewed in the “NENA Standard for NG9- 1-1 GIS Data Model” document. Specifics regarding address point placement methodologies should be reviewed in the “NENA Information Document for Development of Site/Structure Address Point GIS Data for 9-1-1” document. There are other useful resources and training, as well, thatand CAPCOG has created and will can provide. several of these on its own Web Site.
Sample 1

Related to Transitional GIS Data Requirements

  • Data Requirements ‌ • The data referred to in this document are encounter data – a record of health care services, health conditions and products delivered for Massachusetts Medicaid managed care beneficiaries. An encounter is defined as a visit with a unique set of services/procedures performed for an eligible recipient. Each service should be documented on a separate encounter claim detail line completed with all the data elements including date of service, revenue and/or procedure code and/or NDC number, units, and MCE payments/cost of care for a service or product. • All encounter claim information must be for the member identified on the claim by Medicaid ID. Claims must not be submitted with another member’s identification (e.g., xxxxxxx claims must not be submitted under the Mom’s ID). • All claims should reflect the final status of the claim on the date it is pulled from the MCE’s Data Warehouse. • For MassHealth, only the latest version of the claim line submitted to MassHealth is “active”. Previously submitted versions of claim lines get offset (no longer “active” with MassHealth) and payments are not netted. • An encounter is a fully adjudicated service (with all associated claim lines) where the MCE incurred the cost either through direct payment or sub-contracted payment. Generally, at least one line would be adjudicated as “paid”. All adjudicated claims must have a complete set of billing codes. There may also be fully adjudicated claims where the MCE did not incur a cost but would otherwise like to inform MassHealth of covered services provided to Enrollees/Members, such as for quality measure reporting (e.g., CPT category 2 codes for A1c lab tests and care/patient management). • All claim lines should be submitted for each Paid claim, including zero paid claim lines (e.g., bundled services paid at an encounter level and patient copays that exceeded the fee schedule). Denied lines should not be included in the Paid submission. Submit one encounter record/claim line for each service performed (i.e., if a claim consisted of five services or products, each service should have a separate encounter record). Pursuant to contract, an encounter record must be submitted for all covered services provided to all enrollees. Payment amounts must be greater than or equal to zero. There should not be negative payments, including on voided claim lines. • Records/services of the same encounter claim must be submitted with same claim number. There should not be more than one active claim number for the same encounter. All paid claim lines within an encounter must share the same active claim number. If there is a replacement claim with a new version of the claim number, all former claim lines must be replaced by the new claim number or be voided. The claim number, which creates the encounter, and all replacement encounters must retain the same billing provider ID or be completely voided. • Plans are expected to use current MassHealth MCE enrollment assignments to attribute Members to the MassHealth assigned MCE. The integrity of the family of claims should be maintained when submitting claims for multiple MCEs (ACOs/MCO). Entity PIDSL, New Member ID, and the claim number should be consistent across all lines of the same claim. • Data should conform to the Record Layout specified in Section 3.0 of this document. Any deviations from this format will result in claim line or file rejections. Each row in a submitted file should have a unique Claim Number + Suffix combination. • A feed should consist of new (Original) claims, Amendments, Replacements (a.k.a. Adjustments) and/or Voids. The replacements and voids should have a former claim number and former suffix to associate them with the claim + suffix they are voiding or replacing. See Section 2.0, Data Element Clarifications, for more information. • While processing a submission, MassHealth scans the files for the errors. Rejected records are sent back to the MCEs in error reports in a format of the input files with two additional columns to indicate an error code and the field with the error. • Unless otherwise directed or allowed by XxxxXxxxxx, all routine monthly encounter submissions must be successfully loaded to the MH DW on or before the last day of each month with corrected rejections successfully loaded within 5 business days of the subsequent month for that routine monthly encounter submission to be considered timely and included in downstream MassHealth processes. Routine monthly encounter submissions should contain claims with paid/transaction dates through the end of the previous month.

  • Meteorological Data Reporting Requirement (Applicable to wind generation facilities only) The wind generation facility shall, at a minimum, be required to provide the Transmission Provider with site-specific meteorological data including: • Temperature (degrees Fahrenheit) • Wind speed (meters/second) • Wind direction (degrees from True North) • Atmosphere pressure (hectopascals) • Forced outage data (wind turbine and MW unavailability)

  • Minimum Site Requirements for TIPS Sales (when applicable to TIPS Sale). Cleanup: When performing work on site at a TIPS Member’s property, Vendor shall clean up and remove all debris and rubbish resulting from their work as required or directed by the TIPS Member or as agreed by the parties. Upon completion of work, the premises shall be left in good repair and an orderly, neat, clean and unobstructed condition. Preparation: Vendor shall not begin a project for which a TIPS Member has not prepared the site, unless Vendor does the preparation work at no cost, or until TIPS Member includes the cost of site preparation in the TIPS Sale Site preparation includes, but is not limited to: moving furniture, installing wiring for networks or power, and similar pre‐installation requirements. Registered Sex Offender Restrictions: For work to be performed at schools, Vendor agrees that no employee of Vendor or a subcontractor who has been adjudicated to be a registered sex offender will perform work at any time when students are, or reasonably expected to be, present unless otherwise agreed by the TIPS Member. Vendor agrees that a violation of this condition shall be considered a material breach and may result in the cancellation of the TIPS Sale at the TIPS Member’s discretion. Vendor must identify any additional costs associated with compliance of this term. If no costs are specified, compliance with this term will be provided at no additional charge. Safety Measures: Vendor shall take all reasonable precautions for the safety of employees on the worksite, and shall erect and properly maintain all necessary safeguards for protection of workers and the public. Vendor shall post warning signs against all hazards created by the operation and work in progress. Proper precautions shall be taken pursuant to state law and standard practices to protect workers, general public and existing structures from injury or damage. Smoking: Persons working under Agreement shall adhere to the TIPS Member’s or local smoking statutes, codes, ordinances, and policies.

  • Additional Requirements from Authorized Users An Authorized User may have distinct requirements that must be met by all individuals employed by or working for the Authorized User. The Contractor’s Staff Members will be expected to comply with these requirements as a condition of the placement.

  • Technical Requirements for SCPs/Databases 10.5.3.1 BellSouth shall provide physical access to SCPs through the SS7 network and protocols with TCAP as the application layer protocol.

  • EDD Independent Subrecipient Reporting Requirements Effective January 1, 2001, the County of Orange is required to file in accordance with subdivision (a) of Section 6041A of the Internal Revenue Code for services received from a “service provider” to whom the County pays $600 or more or with whom the County enters into a contract for $600 or more within a single calendar year. The purpose of this reporting requirement is to increase child support collection by helping to locate parents who are delinquent in their child support obligations. The term “service provider” is defined in California Unemployment Insurance Code Section 1088.8, Subparagraph B.2 as “an individual who is not an employee of the service recipient for California purposes and who received compensation or executes a contract for services performed for that service recipient within or without the State.” The term is further defined by the California Employment Development Department to refer specifically to independent Subrecipients. An independent Subrecipient is defined as “an individual who is not an employee of the ... government entity for California purposes and who receives compensation or executes a contract for services performed for that ... government entity either in or outside of California.” The reporting requirement does not apply to corporations, general partnerships, limited liability partnerships, and limited liability companies. Additional information on this reporting requirement can be found at the California Employment Development Department web site located at xxxx://xxx.xxx.xx.xxx/Employer_Services.htm

  • EDD Independent Contractor Reporting Requirements Effective January 1, 2001, the County of Orange is required to file in accordance with subdivision (a) of Section 6041A of the Internal Revenue Code for services received from a “service provider” to whom the County pays $600 or more or with whom the County enters into a contract for $600 or more within a single calendar year. The purpose of this reporting requirement is to increase child support collection by helping to locate parents who are delinquent in their child support obligations. The term “service provider” is defined in California Unemployment Insurance Code Section 1088.8, subparagraph B.2 as “an individual who is not an employee of the service recipient for California purposes and who received compensation or executes a contract for services performed for that service recipient within or without the state.” The term is further defined by the California Employment Development Department to refer specifically to independent Contractors. An independent Contractor is defined as “an individual who is not an employee of the ... government entity for California purposes and who receives compensation or executes a contract for services performed for that ... government entity either in or outside of California.” The reporting requirement does not apply to corporations, general partnerships, limited liability partnerships, and limited liability companies. Additional information on this reporting requirement can be found at the California Employment Development Department web site located at xxxx://xxx.xxx.xx.xxx/Employer_Services.htm

  • Supplemental JBoss Software Conditions Software Access and Software Maintenance for Supplemental JBoss Software is intended and available for Development Purposes only and for up to 25 users for each 16 Core Band Subscription of Red Hat JBoss Middleware Software that you purchased. If you deploy or use the Supplemental JBoss Software for Production Purposes or for more than 25 users, you agree to purchase the appropriate Software Subscriptions for each Unit that you deploy or use. Red Hat’s Open Source Assurance Program applies only to the Red Hat JBoss Middleware Software Subscription that you purchased (such as Red Hat JBoss Enterprise Application Platform in the example above) and does not apply to Supplemental JBoss Software. JBoss xPaaS Subscriptions (defined below) are not considered Supplemental JBoss Software. Each installation and use of JBoss xPaaS Subscriptions Software for either Development Purposes or Production Purposes is a Unit and requires a paid Software Subscription.

  • Specific Order Processes and Requirements 1. Distributor will order Software from SAP using and filling out completely such forms and minimum order requirements as SAP may prescribe from time to time and must comply with any then-current order process for the specific Software product. Where applicable, Distributor agrees to use the electronic means provided by SAP for placing orders.

  • Training Requirements Grantee shall:

Time is Money Join Law Insider Premium to draft better contracts faster.