|
|
|
Data Analytics & APIs Situation & Outlook Related Sections - Applications Gallery - States - School Districts - Metros - Congressional District - Counties - Tracts/Neighborhoods - Block Groups - Census Blocks - ZIP Codes - Urban Areas Demographic-Economic Estimates-Projections GIS Thematic Mapping Visual Analysis Tools Ranking Tables National Scope Demographic Change 2000-2010 - States - Metros - Congressional District - School Districts - Counties - Cities/Places - Census Tracts |
Federal Geographic-Demographic-Economic Data Access Using APIs ... perspectives on current and future developments
Role and Scope of APIs. APIs are increasingly used to access Federal Webserver-sourced statistical and related data. APIs have the potential to provide solutions to the aforementioned healthcare analyses. Recent developments by the Census Bureau (see http://www.census.gov/developers/) could fundamentally change not only the way large datasets are accessed but also the ways in which the data are used and interfaced into analytical applications. Several Federal agencies are now developing API-based data access tools. Different agencies are using different API designs making it difficult or impossible to knit together data from different agency APIs. In other cases, data from many important Federal statistical programs are not currently accessible at all using APIs. Without APIs. In absence of APIs to obtain a solution to "the scenario" (above), the steps to the solution are expensive, time consuming, require specialized dataset knowledge and typically provide specific answers rather than having more generalized capabilities. A user/analyst needs to download data from Health and Human Services, combine them with Census-sourced data, then assemble the right data for analysis. As it stands the costs of data access can be prohibitive to perform such tasks, using the "old way" of performing analyses. Consequently analyses may not happen; plans might be developed more based on speculation rather than data-driven, fact-based, knowledge. With APIs such as the Census Bureau has developed would change this situation. Which Data from Which Programs? Access to and use of many Federal geographic and statistical data resources, located in different programs and agencies, could be markedly enhanced through use of APIs. These data could be more easily knitted together. Below an example is presented that compares "design issues" relating to use of existing APIs that might be responsive to "the scenario" solutions. We might use other examples, say, in K-12 education, but the U.S. Department of Education has no known statistical data access APIs, though relevant data exists (Common Core of Data, ACS School District Special Tabulations, among others). Analysts might want to add data on employment, establishments and earnings in healthcare industries (NAICS/types of business) but the U.S. Department of Labor/Bureau of Labor Statistics have no known statistical data access APIs, though relevant data exists (Census of Employment and Wages, Current Employment Survey, Local Area Unemployment Statistics, among others). An Example. To illustrate "where we are," with regard to reaching "the scenario" solution, we briefly compare the API design-related data access issues deployed by the Census Bureau with those being deployed by Health and Human Services (HHS) ... see http://www.healthdata.gov/data-api. The HHS "Data-API" is currently focused on accessing the Hospital Compare data. Solutions to meeting needs like those in "the scenario" require access to raw data as opposed to cataloging data or metadata. The HHS Data-API program is just getting underway. Assessing healthcare resource supply and demand characteristics would require API data from many other HHS programs (Nursing Home Compare, Clinics, Bureau of Health Professions datasets, National Vital Statistics System, Health Resources Services Administration, among others). The Census Bureau uses REST (REpresentational State Transfer) APIs; HHS HealthCare APIs uses RPC (Remote Procedure Call) APIs. These are two different types of APIs with different types of deployment and capabilities. Section 1. Using the HHS HC API -- an Application (scroll section) ... The following code illustrates use of a "post" API instruction to retrieve certain data passed back. In this example, the provider_id (a hospital id) is passed to the server to retrieve a fixed set of data that is returned. The set of data returned is shown in Section 2. procedure TfrmMain.get1Click(Sender: TObject);
var
json: string;
lHTTP: TIdHTTP;
lParamList: TStringList;
begin
memo1.Clear;
json := CRLF +
'{' + CRLF +
' "resource_id": "391792b5-9c0a-48a1-918f-2ee63caa1c54",' + CRLF +
' "filters": {' + CRLF +
' "provider_id": 393303' + CRLF +
' }' + CRLF +
'}';
lParamList := TStringList.Create;
try
lParamList.Add(json);
lHTTP := TIdHTTP.Create(nil);
try
Result := lHTTP.Post('http://hub.Healthdata.gov/api/action/datastore_search', lParamList);
memo1.Lines.Add(result);
finally
lHTTP.Free;
end;
finally
lParamList.Free;
end;
end;
Section 2. HHS HC API -- Returned Results (scroll section) ... The returned results of interest in the following text are basically the name and address of the facility. Other, prospectively important features about the hospital are not returned.
{"help": "Search a datastore table.\n\n The datastore_search action allows a user to search data in a resource.\n\n :param resource_id: id or alias of the resource to be searched against.\n :type resource_id: string\n :param filters: matching conditions to select, e.g {\"key1\": \"a\", \"key2\": \"b\"}\n :type filters: dictionary\n :param q: full text query\n :type q: string\n :param plain: treat as plain text query (default: true)\n :type plain: bool\n :param language: language of the full text query (default: english)\n :type language: string\n :param limit: maximum number of rows to return (default: 100)\n :type limit: int\n :param offset: offset this number of rows\n :type offset: int\n :param fields: fields to return (default: all fields in original order)\n :type fields: list or comma separated string\n :param sort: comma separated field names with ordering\n e.g.: \"fieldname1, fieldname2 desc\"\n :type sort: string\n\n Setting the ``plain`` flag to false enables the entire PostgreSQL `full text search query language`_.\n\n A listing of all available resources can be found at the alias ``_table_metadata``.\n\n .. _full text search query language: http://www.postgresql.org/docs/9.1/static/datatype-textsearch.html#DATATYPE-TSQUERY\n\n **Results:**\n\n The result of this action is a dict with the following keys:\n\n :rtype: A dictionary with the following keys\n :param fields: fields/columns and their extra metadata\n :type fields: list of dictionaries\n :param offset: query offset value\n :type offset: int\n :param limit: query limit value\n :type limit: int\n :param filters: query filters\n :type filters: list of dictionaries\n :param total: number of total matching records\n :type total: int\n :param records: list of matching results\n :type records: list of dictionaries\n\n ", "success": true, "result": {"resource_id": "391792b5-9c0a-48a1-918f-2ee63caa1c54", "fields": [{"type": "int4", "id": "_id"}, {"type": "int8", "id": "seqn"}, {"type": "int8", "id": "provider_id"}, {"type": "text", "id": "hsp_name"}, {"type": "text", "id": "addr_city"}, {"type": "text", "id": "addr_state"}, {"type": "int8", "id": "addr_postalcode"}, {"type": "text", "id": "addr_line_1"}, {"type": "int8", "id": "tel_nbr"}, {"type": "text", "id": "hospital_type"}, {"type": "text", "id": "ownership_type"}, {"type": "text", "id": "hsp_accreditation"}, {"type": "text", "id": "emergency_serv_type"}, {"type": "int8", "id": "county_cd"}], "records": [{"addr_city": "PHILADELPHIA", "provider_id": "393303", "tel_nbr": "2155903745", "seqn": "481", "addr_line_1": "34TH ST & CIVIC CENTER BLVD", "ownership_type": "Voluntary non-profit - Private", "hsp_accreditation": "", "addr_postalcode": "19104", "emergency_serv_type": "Yes", "addr_state": "PA", "_id": 481, "hospital_type": "Childrens", "hsp_name": "CHILDREN'S HOSPITAL OF PHILADELPHIA", "county_cd": "620"}], "_links": {"start": "/api/action/datastore_search", "next": "/api/action/datastore_search?offset=100"}, "filters": {"provider_id": 393303}, "total": 1}}
Section 3. Using the Census API -- an Application (scroll section) ... The following code illustrates use of a "get" API instruction to retrieve certain data passed back. In this example, the state code (geography ... paralleling the HC provider_id) is passed to the server to retrieve a variable set of data items to be returned. In this example, the request is for two items: P0010001 (total population) and NAME (name of the area/state). The API also specifies the statistical program (Census 2010) and dataset (SF1). The set of data returned is shown in Section 4.
procedure TfrmMain.get2Click(Sender: TObject);
var
dl: TDownloadURL;
url:string;
begin
memo1.Clear;
url:='http://api.census.gov/data/2010/sf1?key=KEY&get=P0010001,NAME&for=state:*';
dl := TDownloadURL.Create(self);
try
dl.URL := url;
dl.FileName := execpath+'api1.txt'; dl.ExecuteTarget(nil); dl.Free;
except
dl.Free;
end;
memo1.Lines.LoadFromFile(execpath+'api1.txt');
end;
Section 4. Census API -- Returned Results (scroll section) ... The returned results of interest in the following text are organized in a CSV-like structure. The Census 2010 population is provided for each state; the state name and code are also returned. [["P0010001","NAME","state"], ["4779736","Alabama","01"], ["710231","Alaska","02"], ["6392017","Arizona","04"], ["2915918","Arkansas","05"], ["37253956","California","06"], ["5029196","Colorado","08"], ["3574097","Connecticut","09"], ["897934","Delaware","10"], ["601723","District of Columbia","11"], ["18801310","Florida","12"], ["9687653","Georgia","13"], ["1360301","Hawaii","15"], ["1567582","Idaho","16"], ["12830632","Illinois","17"], ["6483802","Indiana","18"], ["3046355","Iowa","19"], ["2853118","Kansas","20"], ["4339367","Kentucky","21"], ["4533372","Louisiana","22"], ["1328361","Maine","23"], ["5773552","Maryland","24"], ["6547629","Massachusetts","25"], ["9883640","Michigan","26"], ["5303925","Minnesota","27"], ["2967297","Mississippi","28"], ["5988927","Missouri","29"], ["989415","Montana","30"], ["1826341","Nebraska","31"], ["2700551","Nevada","32"], ["1316470","New Hampshire","33"], ["8791894","New Jersey","34"], ["2059179","New Mexico","35"], ["19378102","New York","36"], ["9535483","North Carolina","37"], ["672591","North Dakota","38"], ["11536504","Ohio","39"], ["3751351","Oklahoma","40"], ["3831074","Oregon","41"], ["12702379","Pennsylvania","42"], ["1052567","Rhode Island","44"], ["4625364","South Carolina","45"], ["814180","South Dakota","46"], ["6346105","Tennessee","47"], ["25145561","Texas","48"], ["2763885","Utah","49"], ["625741","Vermont","50"], ["8001024","Virginia","51"], ["6724540","Washington","53"], ["1852994","West Virginia","54"], ["5686986","Wisconsin","55"], ["563626","Wyoming","56"], ["3725789","Puerto Rico","72"]] Next Steps In the world of HTTP applications, REST APIs generally have a broader range of capabilities that RPC capabilities. We promote some degree of standardization in the design of Federal statistical data access APIs so that all agencies are using like procedures. The results could be more useful. Support Using these Resources Learn more about demographic economic data and related analytical tools. Join us in a Data Analytics session. There is no fee for these Web sessions. Each informal session is focused on a specific topic. The open structure also provides for Q&A and discussion of application issues of interest to participants. ProximityOne User Group Join the ProximityOne User Group to keep up-to-date with new developments relating to geographic-demographic-economic decision-making information resources. Receive updates and access to tools and resources available only to members. Use this form to join the User Group. There is no fee. Additional Information ProximityOne develops geographic-demographic-economic data and analytical tools and helps organizations knit together and use diverse data in a decision-making and analytical framework. We develop custom demographic/economic estimates and projections, develop geographic and geocoded address files, and assist with impact and geospatial analyses. Wide-ranging organizations use our software, data and methodologies to analyze their own data integrated with other data. Follow ProximityOne on Twitter at www.twitter.com/proximityone. Contact ProximityOne (888-364-7656) with questions about data covered in this section or to discuss custom estimates, projections or analyses for your areas of interest. |
|
|
