Laravel development for organisations in Heidelberg

Between the university, the hospital and the institutes along the Neckar, more people in Heidelberg work on research questions than in some entire German states. Around the technology park a ring of biotechnology and medical technology has grown out of that, and several large firms maintain research space here.

Software in this environment rarely comes about as a product. It is a tool for a particular question and is often passed on to the next one afterwards.

Collection and analysis belong together

The typical starting point looks like this. Data is captured, in a spreadsheet, a laboratory instrument, a form. It is analysed later, elsewhere, by somebody else. In between lies a break where meaning regularly gets lost. A column is called “value 2”, and two years later nobody knows which unit it is in.

So the effort sits less in the interface than in carrying meaning along. Units, measurement conditions, and who changed what and when. An application recording that from the start can be analysed later without anybody having to reconstruct it. How we build line-of-business applications like these is under Laravel development.

Changes have to stay visible

Where results are evidenced, the current state is not enough. It has to be recognisable that a value was corrected, by whom and for what reason. Technically that is not a large effort as long as it is planned for. Retrofitted, exactly the period you would have needed is missing.

The same applies to deleted records. An entry vanishing without trace is a problem in a research context, even when the deletion was justified. So the usual approach is to mark records as invalid rather than removing them, with a separate arrangement for the case where somebody asks for their data to be erased.

Data protection is not a formality here

As soon as data can be attributed to people, that changes how things are built. Access is kept tight, test environments get no real data, and analysis runs over aggregated values rather than individual cases wherever possible.

We implement what your data protection officer settles and point out the technical consequences. A requirement such as “data must be deleted after five years” sounds simple and means, in practice, that every derived data set has to be accounted for, down to the backups.

Connecting to systems that exist

An application like this rarely stands alone. There is an instrument connection, an archive, an analysis environment where the numbers are taken further. How we build transitions like these without rebuilding the systems involved is under API and backend development.