search_doffin

Search Norwegian public procurement notices on Doffin.

Signature: search_doffin(query: string, optional, default ''; types: list of string (comma-separated), optional, default None; statuses: list of string (comma-separated), optional, default None; contract_nature: list of string (comma-separated), optional, default None; cpv_codes: list of string (comma-separated), optional, default None; locations: list of string (comma-separated), optional, default None; buyer: list of string (comma-separated), optional, default None; winner: list of string (comma-separated), optional, default None; date_from: string, optional, default None; date_to: string, optional, default None; sort_by: string, optional, default 'RELEVANCE'; include_placeholders: yes/no, optional, default False; limit: integer, items, optional, default 25; offset: integer, items, optional, default 0)

Direct GET

For navigating agents: open the HTML page with parameters in the URL. The result is fetched and displayed without screenshots or form filling.

Open this validated HTML GET URL

https://allemannsdata.com/wiki/kilder/doffin/search_doffin/?query=&types={types}&statuses={statuses}&contract_nature={contract_nature}&cpv_codes={cpv_codes}&locations={locations}&buyer={buyer}&winner={winner}&date_from={date_from}&date_to={date_to}&sort_by=RELEVANCE&include_placeholders=false&limit=25&offset=0

Replace {query}, {types}, {statuses}, {contract_nature}, {cpv_codes}, {locations}, {buyer}, {winner}, {date_from}, {date_to}, {sort_by}, {include_placeholders} with values. Remove unused optional parameters from the URL.

For software and dashboards: Read the operation descriptor. The JSON GET template is https://allemannsdata.com/wiki/api/v1/kilder/doffin/search_doffin?query=&types={types}&statuses={statuses}&contract_nature={contract_nature}&cpv_codes={cpv_codes}&locations={locations}&buyer={buyer}&winner={winner}&date_from={date_from}&date_to={date_to}&sort_by=RELEVANCE&include_placeholders=false&limit=25&offset=0. Open this exact request as JSON.

Parameter	Requirement	JSON type	Description
`query`	optional	string	Free-text search (Norwegian or English), e.g. "IT-drift", "snørydding", "rammeavtale konsulent". Start here.
`types`	optional	union	Filter by notice type. Parent types: PLANNING, COMPETITION, RESULT. Specific types: ANNOUNCEMENT_OF_COMPETITION, DYNAMIC_PURCHASING_SCHEME, QUALIFICATION_SCHEME, ANNOUNCEMENT_OF_INTENT, PRE_ANNOUNCEMENT, ADVISORY_NOTICE, NOTICE_ON_BUYER_PROFILE, ANNOUNCEMENT_OF_CONCLUSION_OF_CONTRACT, CHANGE_OF_CONCLUSION_OF_CONTRACT, CANCELLED_OR_MISSING_CONCLUSION_OF_CONTRACT. Use ["COMPETITION"] + statuses=["ACTIVE"] for open tenders.
`statuses`	optional	union	ACTIVE (open for bids), EXPIRED, AWARDED, CANCELLED.
`contract_nature`	optional	union	WORKS, SERVICES and/or SUPPLIES.
`cpv_codes`	optional	union	8-digit CPV codes, e.g. ["45000000"]. Matches the code and its children. Find codes with search_cpv_codes(). Best combined with a free-text query.
`locations`	optional	union	NUTS-style location ids, e.g. ["NO060"] (Trøndelag), or "anyw" for non-location-bound. See list_location_codes().
`buyer`	optional	union	Buyer organization full name(s) exactly as written on notices, e.g. ["Trondheim kommune"]. Resolved to Doffin's internal buyer id via a free-text lookup; names that match no buyer are reported in "note" and, if none match, no results are returned (rather than an unfiltered search). Pass the 32-hex buyer id from a result's buyer field directly to skip the lookup.
`winner`	optional	union	Doffin's internal supplier id (32-hex). Winner names cannot be used - they are not present in search results to resolve against.
`date_from`	optional	union	Publication date lower bound, "YYYY-MM-DD".
`date_to`	optional	union	Publication date upper bound, "YYYY-MM-DD".
`sort_by`	optional	string	RELEVANCE (default), PUBLICATION_DATE_DESC, PUBLICATION_DATE_ASC, DEADLINE, ESTIMATED_VALUE_ASC, ESTIMATED_VALUE_DESC.
`include_placeholders`	optional	boolean	By default, hits whose buyer fields look like unfilled eForm template values (org id 123456789, placeholder buyer names) are dropped from the results as junk. Set True to keep them, each flagged with "possible_placeholder": true.
`limit`	optional	integer	Gateway page size; default 25, maximum 100.
`offset`	optional	integer	Number of list items to skip; default 0.

Generated JavaScript, Python and response structure

Use JSON when the user requests code, machine-readable data, value extraction or further computation. Use the HTML GET page to identify the correct source and verify parameters.

Example for generated JavaScript and Python

https://allemannsdata.com/wiki/api/v1/kilder/doffin/search_doffin?query=&types={types}&statuses={statuses}&contract_nature={contract_nature}&cpv_codes={cpv_codes}&locations={locations}&buyer={buyer}&winner={winner}&date_from={date_from}&date_to={date_to}&sort_by=RELEVANCE&include_placeholders=false&limit=25&offset=0

Replace URL placeholders and remove unused optional parameters.

JavaScript in a dashboard

const url = "https://allemannsdata.com/wiki/api/v1/kilder/doffin/search_doffin?query=&types={types}&statuses={statuses}&contract_nature={contract_nature}&cpv_codes={cpv_codes}&locations={locations}&buyer={buyer}&winner={winner}&date_from={date_from}&date_to={date_to}&sort_by=RELEVANCE&include_placeholders=false&limit=25&offset=0";
const response = await fetch(url);
if (!response.ok) {
  const failure = await response.json();
  throw new Error(`${failure.error.code}: ${failure.error.message} ${failure.suggestion}`);
}
const result = await response.json();
const data = result.data;

Python without additional packages

import json
from urllib.request import urlopen

url = "https://allemannsdata.com/wiki/api/v1/kilder/doffin/search_doffin?query=&types={types}&statuses={statuses}&contract_nature={contract_nature}&cpv_codes={cpv_codes}&locations={locations}&buyer={buyer}&winner={winner}&date_from={date_from}&date_to={date_to}&sort_by=RELEVANCE&include_placeholders=false&limit=25&offset=0"
with urlopen(url) as response:
    result = json.load(response)
data = result["data"]

Response structure

{
  "source": "doffin",
  "operation": "search_doffin",
  "parameters": {},
  "data": {},
  "entities": [],
  "_meta": {"retrieved_at": "...", "sources": [], "cache": {}},
  "_links": {"self": "...", "source": "...", "wiki": "...", "feedback": "..."}
}

Form for manual use

The form is a fallback for people and browser agents that cannot open the GET URL directly.

query Type: string. Free-text search (Norwegian or English), e.g. "IT-drift", "snørydding", "rammeavtale konsulent". Start here.

types Type: list of string (comma-separated). Filter by notice type. Parent types: PLANNING, COMPETITION, RESULT. Specific types: ANNOUNCEMENT_OF_COMPETITION, DYNAMIC_PURCHASING_SCHEME, QUALIFICATION_SCHEME, ANNOUNCEMENT_OF_INTENT, PRE_ANNOUNCEMENT, ADVISORY_NOTICE, NOTICE_ON_BUYER_PROFILE, ANNOUNCEMENT_OF_CONCLUSION_OF_CONTRACT, CHANGE_OF_CONCLUSION_OF_CONTRACT, CANCELLED_OR_MISSING_CONCLUSION_OF_CONTRACT. Use ["COMPETITION"] + statuses=["ACTIVE"] for open tenders.

statuses Type: list of string (comma-separated). ACTIVE (open for bids), EXPIRED, AWARDED, CANCELLED.

contract_nature Type: list of string (comma-separated). WORKS, SERVICES and/or SUPPLIES.

cpv_codes Type: list of string (comma-separated). 8-digit CPV codes, e.g. ["45000000"]. Matches the code and its children. Find codes with search_cpv_codes(). Best combined with a free-text query.

locations Type: list of string (comma-separated). NUTS-style location ids, e.g. ["NO060"] (Trøndelag), or "anyw" for non-location-bound. See list_location_codes().

buyer Type: list of string (comma-separated). Buyer organization full name(s) exactly as written on notices, e.g. ["Trondheim kommune"]. Resolved to Doffin's internal buyer id via a free-text lookup; names that match no buyer are reported in "note" and, if none match, no results are returned (rather than an unfiltered search). Pass the 32-hex buyer id from a result's buyer field directly to skip the lookup.

winner Type: list of string (comma-separated). Doffin's internal supplier id (32-hex). Winner names cannot be used - they are not present in search results to resolve against.

date_from Type: string. Publication date lower bound, "YYYY-MM-DD".

date_to Type: string. Publication date upper bound, "YYYY-MM-DD".

sort_by Type: string. RELEVANCE (default), PUBLICATION_DATE_DESC, PUBLICATION_DATE_ASC, DEADLINE, ESTIMATED_VALUE_ASC, ESTIMATED_VALUE_DESC.

include_placeholders Type: yes/no. By default, hits whose buyer fields look like unfilled eForm template values (org id 123456789, placeholder buyer names) are dropped from the results as junk. Set True to keep them, each flagged with "possible_placeholder": true.

Result

Source: Doffin and TED. Retrieved 2026-11-04T16:21:51Z in 0.152 seconds.

total_count:

hits:

1 results

id:
2026-117121
buyer:
1 results
1. id:
  974e0dc05f4abc0297df75483e30e1d8
  organization_id:
  874789542
  name:
  Universitetet i Bergen UiB
heading:
Request for Information (RFI) - Software for Objective Structured Clinical Examinations (OSCE)
description:
Request for Information (RFI) Software for the Administration, Delivery, and Analysis of Objective Structured Clinical Examinations (OSCE) 1. Background The Faculty of Medicine at the University of Bergen conducts Objective Structured Clinical Examinations (OSCEs) as part of the assessment process in healthcare education programmes. OSCEs are currently used in both the Medicine and Dentistry programmes. Today the examinations are using Qpercom software. The University wishes to explore the market for software solutions that support the planning, administration, delivery, and analysis of OSCE examinations. The purpose of this Request for Information (RFI) is to gather information about available products, functionality, technical capabilities, and future development plans. This RFI is not a procurement process and does not commit the University of Bergen to any future purchase or contractual arrangement. 2. About the Examination Format An OSCE is an examination format where students rotate through a series of stations involving clinical tasks. Student performance is observed and assessed “live” by examiners. Large examination cohorts require several parallel examination circuits to run simultaneously. Consequently, any proposed solution should be capable of supporting complex examination setups involving multiple students, examiners, stations, and concurrent circuits. 3. Purpose of the Solution The University seeks a solution that supports the complete OSCE workflow, including: Examination planning and setup Administration of students, examiners, and support staff Real-time examination delivery Recording and storage of assessments Monitoring and oversight during examination sessions Analysis and reporting of results Distribution of feedback and results to students 4. Required and Desired Functionality Suppliers are invited to describe how their solution supports the following functional areas. 4.1 User and Role Management The solution should be capable of: Managing multiple user roles, such as administrator, examiner, and student. Providing secure authentication and login capabilities. Importing user data from files, including CSV format. Supporting large groups of students and examiners. 4.2 Station, Task, and Assessment Management The solution should be capable of: Creating, editing, and maintaining OSCE stations and tasks. Creating and managing standardized checklists and assessment forms. Reusing previously developed stations, tasks, and assessments. Supporting different assessment criteria and scoring methods. 4.3 Examination Planning The solution should be capable of: Creating and managing examination circuits. Configuring stations and associated tasks. Assigning students and examiners to circuits and stations. Managing multiple examination circuits running in parallel. Providing an overview of examination logistics and scheduling. 4.4 Examination Delivery The solution should be capable of: Presenting relevant information to examiners during the examination. Displaying which student is assigned to a station at any given time. Providing an intuitive interface for recording assessments. Saving assessment data continuously during examination delivery. Supporting recovery and continuity in the event of technical disruptions. Supporting use on tablets, laptops, and other relevant devices. 4.5 Real-Time Monitoring and Administration The solution should be capable of: Providing administrators with real-time oversight of examination activities. Displaying the status of stations, examiners, and students. Identifying missing assessments, delays, or other irregularities. Providing dashboards or similar monitoring tools. 4.6 Reporting and Data Visualization The solution should support presentation of assessment data and results: By individual student. By task or station. By examiner. Across the examination as a whole. Through tables, matrices, charts, dashboards, or similar visualizations. 4.7 Analysis and Quality Assurance The solution should be capable of: Calculating overall results and aggregated scores. Supporting quality assurance and evaluation of examination delivery. Providing statistical analyses related to tasks, examiners, and student performance. Supporting analyses of reliability and consistency in assessment, including commonly used psychometric measures. Suppliers are invited to describe all available analysis, reporting, and quality assurance capabilities. 4.8 Student Feedback and Results Distribution The solution should be capable of: Distributing individual examination results to students. Presenting results in a clear and understandable format. Providing performance data at station or task level. Optionally providing benchmark comparisons against relevant cohorts or peer groups. The University of Bergen appreciates your interest and looks forward to receiving information about relevant solutions available in the market. Deadline for reply to the RFI: The requested information should be at UiB´s disposal no later than 27th of November 2026. Replies to the RFI can be submitted in the portal or directly to [email protected] When using e-mail use the following subject: Response to RFI ANSK-OSCE Confidentiality UiB will treat all replies as confidential; under no circumstances will information received be released to any third party. We request you to treat our RFI confidential.
location_id:
1 results
1. NO0A2
estimatedValue:
not reported by source
type:
ADVISORY_NOTICE
allTypes:
2 results
1. PLANNING
2. ADVISORY_NOTICE
status:
not reported by source
issueDate:
2026-11-03T11:44:35Z
deadline:
not reported by source
sentToTed:
yes
publicationDate:
2026-11-04
placeOfPerformance:
- Vestland
procurementStrategicLabels:
No results.

Show all fields in HTML

total_count:

hits:

1 results

id:
2026-117121
buyer:
1 results
1. id:
  974e0dc05f4abc0297df75483e30e1d8
  organization_id:
  874789542
  name:
  Universitetet i Bergen UiB
heading:
Request for Information (RFI) - Software for Objective Structured Clinical Examinations (OSCE)
description:
Request for Information (RFI) Software for the Administration, Delivery, and Analysis of Objective Structured Clinical Examinations (OSCE) 1. Background The Faculty of Medicine at the University of Bergen conducts Objective Structured Clinical Examinations (OSCEs) as part of the assessment process in healthcare education programmes. OSCEs are currently used in both the Medicine and Dentistry programmes. Today the examinations are using Qpercom software. The University wishes to explore the market for software solutions that support the planning, administration, delivery, and analysis of OSCE examinations. The purpose of this Request for Information (RFI) is to gather information about available products, functionality, technical capabilities, and future development plans. This RFI is not a procurement process and does not commit the University of Bergen to any future purchase or contractual arrangement. 2. About the Examination Format An OSCE is an examination format where students rotate through a series of stations involving clinical tasks. Student performance is observed and assessed “live” by examiners. Large examination cohorts require several parallel examination circuits to run simultaneously. Consequently, any proposed solution should be capable of supporting complex examination setups involving multiple students, examiners, stations, and concurrent circuits. 3. Purpose of the Solution The University seeks a solution that supports the complete OSCE workflow, including: Examination planning and setup Administration of students, examiners, and support staff Real-time examination delivery Recording and storage of assessments Monitoring and oversight during examination sessions Analysis and reporting of results Distribution of feedback and results to students 4. Required and Desired Functionality Suppliers are invited to describe how their solution supports the following functional areas. 4.1 User and Role Management The solution should be capable of: Managing multiple user roles, such as administrator, examiner, and student. Providing secure authentication and login capabilities. Importing user data from files, including CSV format. Supporting large groups of students and examiners. 4.2 Station, Task, and Assessment Management The solution should be capable of: Creating, editing, and maintaining OSCE stations and tasks. Creating and managing standardized checklists and assessment forms. Reusing previously developed stations, tasks, and assessments. Supporting different assessment criteria and scoring methods. 4.3 Examination Planning The solution should be capable of: Creating and managing examination circuits. Configuring stations and associated tasks. Assigning students and examiners to circuits and stations. Managing multiple examination circuits running in parallel. Providing an overview of examination logistics and scheduling. 4.4 Examination Delivery The solution should be capable of: Presenting relevant information to examiners during the examination. Displaying which student is assigned to a station at any given time. Providing an intuitive interface for recording assessments. Saving assessment data continuously during examination delivery. Supporting recovery and continuity in the event of technical disruptions. Supporting use on tablets, laptops, and other relevant devices. 4.5 Real-Time Monitoring and Administration The solution should be capable of: Providing administrators with real-time oversight of examination activities. Displaying the status of stations, examiners, and students. Identifying missing assessments, delays, or other irregularities. Providing dashboards or similar monitoring tools. 4.6 Reporting and Data Visualization The solution should support presentation of assessment data and results: By individual student. By task or station. By examiner. Across the examination as a whole. Through tables, matrices, charts, dashboards, or similar visualizations. 4.7 Analysis and Quality Assurance The solution should be capable of: Calculating overall results and aggregated scores. Supporting quality assurance and evaluation of examination delivery. Providing statistical analyses related to tasks, examiners, and student performance. Supporting analyses of reliability and consistency in assessment, including commonly used psychometric measures. Suppliers are invited to describe all available analysis, reporting, and quality assurance capabilities. 4.8 Student Feedback and Results Distribution The solution should be capable of: Distributing individual examination results to students. Presenting results in a clear and understandable format. Providing performance data at station or task level. Optionally providing benchmark comparisons against relevant cohorts or peer groups. The University of Bergen appreciates your interest and looks forward to receiving information about relevant solutions available in the market. Deadline for reply to the RFI: The requested information should be at UiB´s disposal no later than 27th of November 2026. Replies to the RFI can be submitted in the portal or directly to [email protected] When using e-mail use the following subject: Response to RFI ANSK-OSCE Confidentiality UiB will treat all replies as confidential; under no circumstances will information received be released to any third party. We request you to treat our RFI confidential.
location_id:
1 results
1. NO0A2
estimatedValue:
not reported by source
type:
ADVISORY_NOTICE
allTypes:
2 results
1. PLANNING
2. ADVISORY_NOTICE
status:
not reported by source
issueDate:
2026-11-03T11:44:35Z
deadline:
not reported by source
sentToTed:
yes
publicationDate:
2026-11-04
placeOfPerformance:
- Vestland
procurementStrategicLabels:
No results.

Will you use the result in generated code?

Open the same result as JSON

Is data missing or incorrect? Send feedback about this result.

Continue exploring

How an AI agent should use this page

Ground rule: Navigate with HTML GET links to keep explanations and relationships. Use the page's JSON alternative only when concrete values must be extracted, compared or computed.

How to use the search_doffin lookup

Replace the placeholders in the HTML GET template; remove optional parameters you do not need.
Check types, units, limits and ID formats in the parameter table.
Follow linked results to canonical pages before combining sources.

Misreading to avoid: An empty list means "no results for this lookup". An error message or unavailable source does not mean the data does not exist.

Source-specific next step

Follow the notice ID to the canonical page; use CPV and location codes to narrow broad free-text searches.

Go to the source page for other operations. Use the JSON template only after the HTML result shows that the parameters and source are correct.

AI agent? Read the complete navigation and programming guide.