​Mapping between Cost Center Codes and Site Hierarchy Codes

Open data API in a single place

Provided by Administração Central do Sistema de Saúde (ACSS), I.P

Get early access to ​Mapping between Cost Center Codes and Site Hierarchy Codes API!

Let us know and we will figure it out for you.

Dataset information

Country of origin
Updated
2023.06.27 03:00
Created
2023.06.27
Available languages
English
Keywords
saude-dos-portugueses, transparencia-sns-gov-pt, hierarquia-de-locais, centros-de-custo
Quality scoring

Dataset description

The hierarchy of health system locations is produced by the ACSS, based on information collected from legislation, officially transmitted by ARS, ULS or hospitals or collected directly and automatically from information systems. Cost centres are born in the analytical accounting of the institutions (ARS, ULS and hospitals) and are manually loaded into the RHV by the institutions. Each cost center relates to one and a single ACSS location hierarchy code. Each ACSS location hierarchy code can correspond to zero, one or more existing cost centers in RHV. **Primary Key** The primary key or unique record identifier of this view and also for the "cost center" granularity is the combination of the following columns: \- [cod_mes]; \- [_-typeinstitution]; \- [cod_institution]; \- [cod_centro_cost]. The primary key or unique record identifier for the granularity "place of hierarchy" is the combination of the following columns: \- [cod_mes]; \- [_hierarchy level]; \- [cod_hier_loc]. **Description of Fields:** **Period:** Specifies the month to which the information applies.  **cod_institution:** Institution code. **cod_centro_cost:** Cost centre code used in the RHV for the institution identified by fields [_institution type] and [cod_institution]. **de_centro_cost:** Cost center code description. **abbrev_institution:** Short name of the institution identified by the fields [type_institution] and [cod_institution]. **de_institution:** Name of institution. **_typeinstitution:** Specifies the type of institution holding the cost centre code. Two values are possible: ARS and ULS. **level_hierarchy:** Represents the "type" and "level" of the hierarchy of locations. The first character represents the type of hierarchy (it can take the values "O" and "H"). The second character is a numeric value between 1 and 9 and represents the hierarchical level. **cod_hier_loc:** Element code mapping with the cost center at the level specified in [_hierarchy level]. **name_uf_serv_depart_hier_loc:** Designation of the element with which it maps the cost centre in the hierarchy of locations and at the level defined in [_hierarchy type] and [_hierarchy level]. **cod_dia_dta_ini_uf_serv_dep:** Specifies the date of creation of the functional unit, service, department or organic unit in the ACSS site hierarchy. YYYYMMDD format. **type_uf_serv_depart:** Defines the typology of functional unit, service or department. **De_type_uf_serv_depart:** Designation of the typology of functional unit, service or department. **cod_area_atuação_princ_serv:** Code that allows to specify the main area of the assignments conferred to the unit, service, department or other type of organic unit mapped in the hierarchy of locations. **des_area_atuação_princ_serv:** Field description [cod_area_atuação_princ_serv]. **cod_level_access:** Code that allows you to specify the scope of access to information in the BI-CSP that will be given to users associated with the cost center. **de_level_access:** Field description [cod_level_access]. **cod_aces_hosp_group:** Code of the ACES or hospital or aggregator group to which the functional unit or service belongs, used at level 4 of the classical site hierarchy. This field is not filled in the codes corresponding to the central services of the ARS or in the codes belonging to the central services of the ULS. **aces_hosp_group:** Name of ACES or hospital or aggregator group with code registered in [cod_aces_hosp_group]. **cod_uls_group:** Code of the ULS or aggregating group to which the functional unit or service belongs, used at level 5 of the classical site hierarchy.This field is not filled in the codes corresponding to the central services of the ARS. **uls_group:** Name of ULS or aggregator group with code registered in [cod_uls_group]. **cod_ars_rs:** ARS code to which the functional unit or service belongs, used at level 6 of the classical site hierarchy. **ars_rs:** Name of ARS registered in [cod_ars_rs]. **cod_mes_ini_mapeam_cc_hier_loc:** Specifies the month in which the cost center and site hierarchy element were first mapped in the past. YYYYMM format. **cod_mes_ini_name_uf_serv_dep:** Specifies the month in which for the first time the cost center and the element of the place hierarchy were mapped in the past with the same name in the place hierarchy. YYYYMM format. **cod_dia_data_refer:** Specifies the mapping reference date. YYYYMMDD format. **Order:** Logical ordering of records. It allows the registers to be sorted in such a way that the registers of the same institutions are kept together by making the usual ordering of the establishment plans.
European data infrastructure with broad catalog discovery, free evaluation access and production-grade API options.
190K+
indexed dataset pages
32
countries and EU institutions
2019
API-first since
Free API quota
for evaluation and prototypes
SLA
history and push on production APIs
FAQ

Questions before production use

Practical answers on evaluation, licensing, freshness, versioning and support.

api.store is built and operated by Apitalks s.r.o. Company details and a direct contact path are linked in the footer for vendor checks and procurement review.
Yes. Selected APIs include a free API quota, so your team can validate coverage, freshness, response shape and workflow fit before asking for a production plan.
Often yes, but usage rights depend on the source license and dataset. We surface source, license and update metadata where available, and can help review terms before a production integration.
Maintained APIs include update metadata where available. For production integrations, we can add history, monitoring and push updates so changes are easier to detect and act on.
Production APIs can add SLA, stable identifiers, versioning support, history, push updates and direct support around the data your product or AI workflow depends on.

Didn't find the API you need?

Let us know and we will figure it out for you.

European data discovery with free evaluation access and production-grade API options.

Copyright © 2026. Made by Apitalks