Want to help?

Help expand the guide - share knowledge and code that can be reused across register-based research projects

Published

August 11, 2026

This guide is continuously evolving, and many researchers have solved the same classic problems each in their own project - without the code or the experience ever being shared. If we share, we all save time.

There are two kinds of contribution we are especially looking for: knowledge (recurring problems, methods and packages we should cover) and code (concrete, reusable solutions). You do not need anything finished - drafts and good pointers are gold too.

Share your knowledge

Where do register researchers keep hitting the same things? Point us in the right direction:

Recurring problems

Which pitfalls do you meet again and again? (immortal time, exclusion order, prevalent vs. incident, time-varying confounding …) - so we can describe them in one place.

Epidemiological methods

Designs, bias and analysis approaches specific to register data - and how to explain them simply for beginners.

Packages that already exist

Do you know an R package that solves a register problem? (e.g. heaven, Epi, MatchIt, EpiForsk, comorbidity …) Then we point to it instead of reinventing.

Share your code

Concrete, reusable solutions. It does not need to be validated - we are happy to work on from a draft:

Ethnicity

Deriving ethnicity/origin and generations from BEF/IEPE.

Medication and medication use

Exposure measures from LMDB: DDD, weighted use, PDC/MPR, insulin dosing, lag time and long-term prescriptions.

Family linkage

Linking parents, children and siblings via CPR/family id - e.g. to transfer exposures or covariates across generations.

Nordic Multimorbidity Index (NMI)

Computing NMI from LPR. We have a starter page - validated code and variants are very welcome.

Socioeconomic classification

Education, income and employment, e.g. by SEPLINE. We have a starter page - validated code welcome.

Time-varying variables

Variables that change over follow-up - blood tests, BMI, weight - in long format / intervals.

Simulated data

Simulated/synthetic datasets, so the guide’s code examples can be run without access to real DST data.

It does not need to be finished or validated - we are happy to work further with drafts. If you have something else entirely that solves a general problem in register data, you are very welcome to get in touch as well.

How to contribute

Two ways - pick whichever suits you:

  • Email us (easiest): saras@clin.au.dk. Send code, a draft, or just an idea - we’ll add it. You need neither git nor GitHub.
  • Open a pull request on GitHub (if you’re comfortable with it): The guide’s source files live in a GitHub repository: github.com/steno-aarhus/registers-guide. Every page in the guide is a .qmd file, and the website itself is built automatically from them. A pull request is a proposal of concrete changes to those files that we can review and merge.
How do I send a pull request? (step by step)

A pull request is only a proposal - it is never merged automatically. We are notified, review the change, and merge it only once we have approved it. An outside contributor can therefore propose a change but cannot alter the page directly; only people we have explicitly given write access can merge. So nothing goes live behind our backs.

  1. Create a (free) GitHub account if you don’t have one.
  2. Find the file. Every page is a .qmd file in the repository root, and the filename is shown in the address bar: the page at .../09a_understand-lpr.html is the file 09a_understand-lpr.qmd (the part before .html is the .qmd name).
  3. Click the pencil icon (“Edit this file”) on the file. If you don’t have write access (outside contributors don’t), GitHub automatically makes a fork - your own copy of the project - and your changes are saved there, not in the original.
  4. Commit (“Commit changes”) and click “Create pull request”. To add a brand-new page instead, use “Add file” → “Create new file” at the top of the file list - that is sent as a pull request too.
  5. We review, comment if needed, and merge when it’s ready - and the website updates automatically.

Everything can be done in the browser; you don’t need to install git. If you prefer email, that’s perfectly fine.

Back to top