Custom neurodiversity assessment software
If you have standardised instruments administered digitally, you are not building a questionnaire. The administration rules are fixed, the norm tables come from the rights holder, the outcome is health-related, and the interface influences whether you measure what you set out to measure. Appfront builds software that enables a professional to administer, score and record such instruments. The software supports the process; the interpretation of the outcome rests with the professional conducting the assessment.
How screening differs from testing
A test measures whether someone knows the material. There are right and wrong answers, a pass mark the training institution may set itself, and the result concerns the work that was produced. A standardised instrument for cognitive screening works differently. The raw score means nothing on its own: it only acquires meaning through comparison with a norm group of similar age and background, and that comparison holds only if the administration was carried out as it was when that norm group was compiled. The instructions, the order of items, whether returning to earlier items is permitted, the presence of practice items and any time limit all belong to the instrument. They are not design choices you may improve during a design session.
The task therefore shifts. You are not building a form that stores answers, but an administration environment that adheres to the instrument's rules, records the circumstances under which the assessment took place, and presents the outcome in a way that no one confuses with a conclusion. The professional conducting the assessment weighs the outcome against the history, the conversation and whatever else is known. The software calculates and records; that professional interprets.
The organisations that commission software for this sit at different points in the chain. A practice or youth care organisation uses instruments within a support or treatment programme. A school or special-needs partnership wants to know what support a pupil needs and works with an orthopedagogue or psychologist to determine it. An occupational health service or reintegration agency looks at what someone needs in order to work, with a client at a distance who may only see a small part. A training provider or employer wants to organise support for people who learn or work differently, without collecting data they are not entitled to. What these situations share is an instrument that cannot be repurposed and an outcome that may only be read by a limited circle. What sets them apart is who is responsible, and that then determines almost everything in the access model and the retention period.
Are you in the right place? This page is about standardised instruments and outcomes related to health. If you want to test knowledge, skill or suitability, with an item bank, your own cut-off score and a scoring model you set yourself, you need custom assessment software development. That raises the question of how to test fairly and efficiently. Here, the question is how to respect an instrument that isn't yours, and how to handle what comes out of it with care.
The score gains meaning from outside
A raw number of points means nothing without the norm group it is compared against. That comparison is part of the instrument.
The instrument is not yours
Item texts, administration rules and norm tables are usually protected. What you are permitted to administer digitally is set out in the licence.
The outcome carries more weight
A finding about cognitive functioning is health-related and falls under special category personal data.
Administering an instrument without changing it
Moving from paper to screen may seem like a matter of retyping, yet that is exactly where the damage occurs. A progress bar makes visible how much longer it will take and thereby changes the pace. A button that allows going back changes an instrument that was normed on first instinct. An extra answer option such as don't know seems friendly, but it was not part of the original administration and no norm group has used it. The same goes for automatic saving that unintentionally closes an assessment, for an animation between two items, and for an instruction shortened because it did not fit on a mobile screen.
An assessment environment should therefore enforce the rules of the instrument explicitly, rather than leave them to the builder. What is the fixed item order, which practice items come first, can respondents go back, is there a stopping rule after a number of consecutive failures, and is time measured per item or per block? If the instrument has a time limit, the measurement must exclude screen loading time and connection delay, otherwise you end up measuring the infrastructure. Administration across different devices requires attention to the reverse problem: an item that can be taken in at a glance on a large monitor becomes a scrolling task on a phone, and that is a different task.
Equally important is what is recorded alongside the answers. The circumstances determine how the outcome should be read, and they cannot be reconstructed afterwards. Think of the device and screen size, the input method, whether headphones or sound were used, the language in which the assessment was taken, whether someone was present, whether the instruction was read aloud, how often and for how long breaks were taken, and whether the administration was interrupted. This data belongs with the administration itself, not in a log that is cleared away after a while.
Language deserves its own paragraph, because this is where most good intentions fall apart. An instrument standardised in Dutch becomes a different instrument once translated: words differ in frequency and difficulty, and the norm group never took that translated version. A translate button in the interface is therefore not an accessibility feature but an intervention in the instrument, and it should only appear if the rights holder supplies a version in that language together with the normative tables that go with it. What you can do is make the surrounding environment multilingual: the explanation of what is going to happen, the consent question, the navigation and the feedback. If an interpreter is involved or the instructions are read aloud, that belongs in the administration conditions, not in the professional's loose notes.
Finally, assessments don't always take place on a good connection. On site, in a classroom or at someone's home, an interruption must not cause data loss, so responses are stored safely locally and synchronised later, with a clear rule for the case where the same assessment has been continued on two devices. Just as important is what the professional sees when they return to an interrupted assessment: where it stopped, how long the interruption lasted, and whether the instrument allows it to be resumed later. Sometimes it doesn't, and in that case the environment should say so rather than offer the button anyway.
Norm tables and scoring you do not devise yourself
The step from raw score to derived score is calculation with edge cases, and it is precisely the part you must not improvise. Norm tables are built per norm group, often in age bands and sometimes with a breakdown by educational level or language background. The software must know what happens when someone falls on the boundary between two bands, when the raw score lies outside the range of the table, when some items are missing and the administration therefore cannot be scored, and whether values may be interpolated between table entries. These are not design questions: the answers come from the instrument's manual and otherwise from enquiry with the rights holder.
In practice we work it out as follows. The scoring rules and tables are taken in from the source and are not retyped by hand from a printout. The implementation is tested against the worked examples that accompany the instrument, including the boundary cases. Every administration records which version of the instrument and which norm table were used, so that a report from last year can still be reproduced exactly. When a new norming appears, it is placed alongside the old one rather than replacing it: existing administrations stay scored against their own table, and recalculation is an explicit action with a visible trail. An outcome that quietly shifts after an update is useless in this domain.
The software calculates, the professional interprets
How the outcome appears on screen determines how it is read. A number on its own suggests a precision that is not there, so alongside the derived score we show the norm group it was compared with and the margin of error that belongs to the instrument. The wording remains descriptive: a score lies below or above the average of the norm group. What that means for this person is not stated, because that judgement is the professional's to make. If the instrument itself signals a cut-off value that warrants further investigation, that is a feature of the instrument that we carry over, not a conclusion the software adds.
That also applies to what we do not build, and we would rather say so plainly. No feature that draws a conclusion or a label from the answers, no automatically generated advice that could be read as a finding, and no self-devised risk score placed alongside the outcome of the instrument. Nor an overview that lays scores from people within an organisation side by side, because such a list invites use for which the data were not collected. If you wish to work with signals, these come from the instrument itself, in the instrument's own wording, with the norm group included. This is not modesty about what software can do; it is recognition that the meaning of these outcomes arises in the conversation that follows, and that a system which fills in that meaning in advance gets in the professional's way.
The same principle runs through the way of working. An assessment first receives the status draft and does not leave the system as a report until the competent professional has approved it, with room for their own commentary and for observations made during the assessment. The record notes who supervised the assessment and who reviewed the outcome, even where these are two different people. Automatically sending a result to the person concerned or to a supervisor is therefore ruled out: there is always a human being between the score and the conversation.
What screening software must be able to do
These components are connected. An assessment that enforces the rules is of little value if the scoring cannot be traced, and careful reporting does not help if everyone in the organisation can view the individual answers.
Instrument management with versions
Item order, practice items, discontinuation rules and norm tables as a fixed configuration, with multiple versions side by side and an assessment tied to one version.
Assessment that enforces the rules
One task per screen, moving back only where the instrument permits it, timing that keeps loading time off the clock, and pausing and resuming without loss.
Scoring from the source of the instrument
Raw score to derived score according to the tables of the rights holder, with recorded rules for borderline cases and a calculation that remains reproducible.
Adjustments that are recorded
Font size, contrast, calm on the screen, read-aloud instructions and additional breaks adjustable per person, with each adjustment visible for every assessment.
Two reports from one assessment
A view for the professional showing scores, norm group and assessment conditions, and a view in plain language for the person concerned and their supervisor.
Access at the level of rules
Roles that determine who may see individual answers and who sees only the outcome, with access that is logged and a record that is not open across the whole organisation.
Accessibility is a design requirement, not an afterthought
In this domain accessibility is not an extra added at the end, because it bears on the validity of what you measure. If navigating the environment demands attention, that attention does not go to the task. An interface that adds stimuli therefore partly measures itself. This is an uncomfortable thought for a design team used to atmosphere and motion: here, removing movement is the better choice. No animations between items, no video that starts by itself, no elements that jump into place once something loads, no decorative background behind a task, and no two instructions in the same sentence. What remains is calm, predictable and plain, and that is exactly right.
The hard side is simply work that has to happen early. WCAG 2.2 at level AA is the starting point, with EN 301 549 as the European standard for the digital accessibility of ICT, which public bodies refer to; government organisations also publish an accessibility statement on the state of their services. In practice that means a logical focus order, full keyboard operation, sufficient contrast, information that isn't conveyed by colour alone, touch targets large enough to use, and error messages that explain what has gone wrong. Add one requirement specific to assessments: a session must not time out while someone is thinking about an item. For a more detailed look at how we approach this, see custom accessible software development.
Accessible is not the same as adapted, and that is where the tension in this work lies. A larger font, fewer items on screen at once, a read-aloud instruction or an extra break are reasonable adjustments that allow someone to show what they can do. At the same time, an adjustment can affect the conditions under which the norm group was built, particularly where a time limit is part of the instrument. We don't resolve that by banning adjustments or applying them silently, but by making them possible, recording them per person and keeping them visible in the report. The professional then knows what they are looking at and can weigh the comparability.
Two practical points often surface late. Assistive software and visual material don't always go together: if someone reads the screen with a screen reader, a task that relies on layout, colour or position simply won't work. The question then is whether a different version of the instrument exists for that situation, rather than whether we can invent an alternative ourselves. The second point is that the language of the surrounding environment is not the same as the language of the instrument. You must not simplify the instruction for a task, but you can simplify everything around it: what someone is starting, how many parts it has, what happens with the outcome, and who to turn to with a question. That surrounding layer determines whether someone starts with confidence or with the brakes on.
Settings also belong to the person, not to a target group. Someone chooses their preferences once or has them assigned at intake, and they then apply to every assessment without being asked again. We test with people, not just with a scanner: automated checks catch some of the problems, but whether a task feels calm and the instruction lands at first reading only shows up when someone uses it.
- WCAG 2.2 at level AA as the starting point, not as the final check
- Full keyboard operation and assistive software support
- Calm and predictability over visual decoration
- No session that times out during an assessment
- Settings per person, not per target group
- Every adjustment recorded and visible in the report
- Tested with real users, not just with a scanner
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Special category personal data, purpose limitation and retention period
An outcome about cognitive functioning is health-related, and therefore falls under the special categories of personal data in the GDPR. For that category there is no ordinary balancing exercise: processing is in principle prohibited, unless a specific exception applies, for example because care is provided by a professional bound by confidentiality, or because the data subject has given explicit consent. This is not a tick box in a processing register but a design requirement: it determines who may see the data, which fields may exist at all and how long they are kept. The role you work in matters more than which instrument you administer.
Purpose limitation is the hardest principle in this domain, because the temptation is strong. Data collected to give someone suitable support is not simply usable for selection, for assessing employees, for benchmarking between locations or for research. Each of those purposes needs its own legal basis and usually its own conversation. Data minimisation applies directly here: the intake form only asks for what is used in the assessment or the reporting, and fields that nobody can explain the purpose of disappear from the model. We therefore prefer to build a small data model with tightly defined roles rather than a broad model with many permissions. You can read how we set up a wider record of processing activities in building a GDPR compliance platform.
The surrounding setup is standard work that you should arrange in advance. Your organisation is the controller, a builder or hosting provider is the processor, and this is recorded in a data processing agreement that also lists the sub-processors. For this category of data, a data protection impact assessment (DPIA) is the starting point, not the exception. Further requirements: encryption in transit and at rest, hosting in an environment and jurisdiction you can explain, identifying data kept separate from answers so that an export for management or research does not carry names, access that is logged, and access restricted by role rather than left open across the whole organisation. For the wider requirements of a care environment, see building healthcare software.
One situation deserves a specific warning, because this is where things go wrong in practice. Where an employer is in control, the room to process employees' health data is very limited; the Dutch Data Protection Authority's position is that this must go through the occupational health service or the company doctor, and that the employer receives only what the person needs in order to do their job. In software, this means a strict separation: the professional works within the file, the employer sees no answers and no scores, and what reaches them is advice on workplace adjustments. Anyone who does not build that distinction into the roles is building a system that puts its own users in trouble.
What is often overlooked is the administrative side. Administrators and developers in practice have access to a production environment, and with this category of data that is something you must set up deliberately rather than leave to habit. Work with test data that contains no real people; grant production access only temporarily and with a recorded reason; and ensure error messages and log files carry no answers or scores. The same applies to exports, because a printout to a spreadsheet is the quickest way special category personal data leaves your environment: exporting is a right that only a few roles should have, and it is logged. An incident should also follow a practised path, with someone who knows when a notification to the regulator and to the data subjects is required.
Retention periods that differ by role, and reporting in two directions
No single retention period suits this kind of software, because the period follows from the role in which the data was recorded. For a care file there is a statutory retention obligation that runs for a long time, whereas a school, an occupational health service or a reintegration programme should apply a short period. We therefore attach the clock not to the whole record but to categories of data: individual answers and time measurements may be deleted sooner than the established outcome, which should remain in the file. The system then deletes genuinely, with a trail showing that deletion took place, and it knows what to do with an abandoned assessment rather than leaving it forever as a draft.
The same choices come back on the reporting side. A single assessment produces two views: a version for the professional, with raw scores, norm group, margin of error and test conditions, and a version in plain language for the person being assessed and, if they wish, for their supervisor. That second version describes what was done, what came out of it and which agreements follow from it, without labels and without numbers that drift around unexplained. A supervisor gets what they need to act, not the entire file. And because someone has the right to access their data and to have inaccuracies corrected, that version is not an attachment produced afterwards but a fully fledged output of the system, with room for the person's own view.
When an existing platform is the better choice
This is not an empty corner of the market. Publishers of assessment instruments have their own digital testing environments, and for some of the readers of this page those are simply the right answer. If you want to administer and score licensed instruments, and nothing else, you are best served by buying that ready-made from the party that is also responsible for the norming. A new norm comes with it, the scoring is the rights holder's scoring, and you do not have to demonstrate that your own implementation is correct. We would rather say that now than halfway through a tender process.
There is also a boundary that money or ambition cannot shift. If the licence states that the instrument may only be administered within the publisher's environment, then a custom administration module is no longer a design question but ruled out. What remains is the process around it, and that is often exactly where the pain lies. So begin a project by putting the licence terms on the table: what may be done digitally, which norm groups may be used, which output you may display, and whether the outcome may enter your own system. Those answers almost automatically determine what is worth building.
Custom development therefore usually pays off not on the assessment itself, but on everything around it. Think of intake and triage with your own questions, a waiting list, referral and feedback, working across several locations with different professionals, your own observation or interview lists that need to land in the same file alongside a licensed instrument, reporting in your organisation's own terms, and a role model that separates more strictly than a general-purpose platform can. In an occupational health service or an employer context, that last point is not a luxury but the core of the brief. Accessibility is a reason too: if the platform does not reach the level you need for your target group, you are stuck with someone else's roadmap.
So in a first conversation we look not at the feature list, but at the three constraints that determine the rest: what the licence allows, in which role you process the data, and who may see which output. Until those three are settled, every functional wish is only a sketch, because they can rule each other out. An outcome you want to show a client may be an output you are not permitted to share. An instrument you want to take digitally may be tied to a single environment. Once that is clear, the conversation about intake, file, reporting and integrations becomes concrete, and it usually turns out that the gain lies not in the assessment itself but in the process around it.
In practice we therefore often arrive at the middle route. The assessment takes place where it belongs, while intake, the file, permissions and reporting sit in your own environment, with an integration or a controlled transfer of the outcome, and without unnecessarily copying individual answers. You can read what such a records layer looks like in developing a case management system. The flip side comes with it: if you build it yourself, keeping up with norms, accessibility requirements and privacy frameworks falls to your own organisation, and that is work that is never finished.
- Vendor platform if you only take licensed instruments
- Platform if the licence does not permit administration outside it
- Custom development for intake, triage, file and feedback
- Custom development for your own lists alongside a licensed instrument
- Custom development if roles need to be more strictly separated
- Middle route: administration with the publisher, case file and reporting with you
Frequently asked questions about screening software
No. The software supports a professional in administering an instrument, calculating scores according to the established norm tables and recording the administration in a case file. Interpreting the outcome remains with that professional, who weighs the background, the context and the conversation. A screening result is a signal that may warrant further investigation, not a conclusion about a person, and the software presents it as such.
Two things. The data falls under a stricter regime, because an outcome concerning cognitive functioning is health-related and therefore counts as special category personal data. And the scoring is not freely available: for a standardised instrument, the administration rules and norm tables belong to the rights holder, and you may not devise or access them yourself. If you only want to test knowledge or skills, without those two requirements, a generic administration environment is the better fit.
Only if the rights holder permits it. Item texts, administration rules and norm tables are usually protected and provided under licence, sometimes only for use within the publisher's platform. That is one of the first things we check: whether this instrument may be administered digitally, which norm groups may be used and what output you may display. Without that agreement, you would be building an administration environment for instruments you are not permitted to put in it.
By making them possible and recording them. A larger font, fewer on-screen distractions, read-aloud instructions or a break between sections are reasonable adjustments. At the same time, an adjustment may affect the conditions under which the norm group was built, for example if the instrument has a time limit. The software therefore records for each administration what was adjusted, so the professional can take that into account and it remains visible in the report.
Wherever you choose, and no longer than you can justify. The retention period depends on the role you work in: for a care file there is a statutory retention obligation that runs for a long time, whereas a school, an occupational health service or an employer should, by contrast, apply a short period. In the data model, we separate the raw answers from the outcome, so the detail can be deleted sooner than the conclusion that should remain on file.
Yes, and that is more than an export button. Someone is entitled to inspect their own data, and a printout full of scores without explanation helps nobody. That is why we build two views of the same assessment: a version for the professional with raw scores, norm group and administration conditions, and a version in plain language that describes what was done, what came out and which agreements follow from it.
Related services
Assessment software for testing and evaluation
If the subject is knowledge, skill or suitability, with its own item bank and a cut-off score you set yourself, then building assessment software is the right starting point. No third-party norm tables, no health-related outcome.
Software for mental health care
If the question sits within a care context, with records, treatment pathways and professional confidentiality, then custom mental health software development is a better fit, as the intake is only one step in the process.
Intake before the consultation begins
The work before intake, from referral and triage to gathering what is already known, belongs to custom intake software development. Data minimisation applies just as strictly there.
Compare your assessment process with your licence
Tell us which instruments you administer and what the licence says about them, what role you work in and who ultimately sees the result. These three answers usually show whether you need a platform, custom software around the administration, or a combination of both. And whatever gets built, the professional remains the one who interprets the result.