Reproducible Research Insights with Berk Silemek and Lukas Winter


By Mathieu Boudreau

The project repository containing all the shared design files and code, which is hosted on the authors institute.

This MRM Reproducible Research Insights interview is with Berk Silemek and Lukas Winter, researchers at Physikalisch-Technische Bundesanstalt (PTB) in Berlin, Germany. We chose to feature their paper entitled “Wirelessly interfacing sensor-equipped implants and MR scanners for improved safety and imaging” because they openly shared design files and software for the MRI implant sensor they developed.

To learn more, check out our recent MRM Highlights Q&A interview with Berk Silemek and Lukas Winter.

General questions

1. Why did you choose to share your code/data?

There aren’t many reasons not to share code/designs, apart from the extra work needed on the documentation side. Sharing means: more impact, better reproducibility of scientific results, saving of resources (both time and money) for others, easier transfer of results to products, faster innovation cycles, educational access to the findings, etc. Sharing should be the gold standard and the question should rather be: Why did you choose not to share your code/data?

2. What is your lab or institutional policy on sharing research code and data?

In our MR department, we strongly pursue open-science practices of all types: data, code, hardware. At the same time, we are bound to institutional policies, of course. So, in the end, it has to be decided case by case what can and will be shared. We must say, however, that our whole organization, Physikalisch-Technische Bundesanstalt (PTB), is increasingly acknowledging and embracing the open-science idea. In general, we get a lot of support and face very few restrictions in this respect.

3. Have you observed any tangible benefits or impact on your research or career as a result of adopting reproducible research practices?

Yes, sharing is caring, and we feel that the impact of our work increases substantially as a result of sharing our designs. For example, we received a lot of feedback to our earlier open-source hardware projects (e.g., the measurement robot COSI Measure ( that were reproduced and helped others in their research. This feedback helped us to improve our existing workflow and our own design (i.e., releasing COSI Measure version 2.0). The best aspect was meeting a lot of incredible people and labs, and starting to work collaboratively on further improving designs useful to everyone’s research, even if it is in completely different domains.

3D illustration of the wireless device

4. How do you think we might encourage researchers in the MRI hardware community to contribute more open-source content along with their research papers?

Hmm, that’s a good question. Prizes, reproducibility challenges, hackathons, better infrastructure/blueprints for sharing, but also reviewers asking for more sharing of designs might help to motivate this. But the thing that could prove crucial would be for the projects’ PIs to state, in their grant applications, that the resulting designs will be shared under an open-source license. If I make that promise at the beginning, which by the way may help to secure the funding as well, it’s easier in the end to implement. This would also be an important signal to the funding bodies that open-source science practices are also needed in the hardware domain, helping to shape guidelines and policies, and maybe even obtain dedicated resources to fund open-source hardware projects and infrastructure. We have observed this evolution in open-access policies and now also in open-source software, so hardware would be a logical and great next step.

It would also be helpful to really reflect on the implications of sharing. The goal is not to make a “new” device and produce a paper to go with it; the goal should instead be to address the bigger picture: how can I advance science the most? The answer includes making my resources available to others through open-source designs, and enabling them to build upon previous work openly, similar to citing a paper. Also, if I can cite/reuse other designs and improve them, this will promote easier reproducibility/transition of my own results to allow a wider benchmarking and quicker advancement in the field. 

Questions about the specific reproducible research habit

1. What advice do you have for people who would like to share details and open-source content about their MR hardware, so as to make their research reproducible?

Maybe our first piece of advice would be: have a look at other similar and successful open-source hardware projects and learn from their documentation/communication strategies. Some more practical tips: provide all files, the production pipeline, and the machines that are necessary to reproduce but also distribute your design, which includes source files (e.g., a CAD model in FreeCAD) and not only production files (e.g., 3D models in STL). Try to use open-source software tools that everyone can easily access (e.g., Python). Publish those files with an open-source hardware license (e.g., CERN OHL v2). Use repositories that are easily accessible, have version tracking and other useful tools for collaboration (e.g., GitLab or GitHub). If you have further questions, reach out to the community, e.g. the Open Source Imaging Initiative (  — they are happy to help.

2. What are your hopes with regard to how the MRI hardware community might use the code and design files you shared?

We hope that by sharing the design files for our sensor-equipped implant, we can offer the community low-level access to and rapid prototyping of the methodology that we are proposing. We would like sensor-equipped implants to communicate with an MR scanner because we envision that this has strong potential to improve patient safety, reduce the burden and responsibilities shouldered by clinical personnel, and boost imaging performance and clinical efficiency. If more scientists and developers from academia and industry investigate this new approach, it is more likely that this methodology will be implemented in the clinic. We hope that sharing all the resources that we developed (hardware, firmware, software and their documentation) will increase our chances of reaching this goal in the shortest time possible.

OSI² ONE open-source low-field MRI build workshop in September 2023 at the PTB in Berlin

3. Your Open Source Imaging Initiative (OSI2) has existed since 2016 and has been a major part of the movement for open science in the area of MRI developments. Can you tell us about its origins, its current state, and where you see it going?

Driven by the lack of accessible MRI resources, OSI² was founded to stimulate the development of open-source software and hardware around MRI research. Because too few designs were (and still are) available evaluating/comparing performances of scientific breakthroughs, resources were (and are) being wasted on replicating existing work or reverse engineering closed-source commercial solutions. This problem of inaccessibility extends to the technology itself: MRI machines, powerful tools for diagnosis and treatment, remain prohibitively expensive, which limits many patients’ access to them. OSI² believes that sharing resources globally is a much more efficient way to tackle these challenges. Initially, we just wanted to encourage the community to share and support more software and hardware projects by providing a platform where their work can be highlighted. We wanted to form a community that believes in the idea of open-source science. But the ultimate goal was always to join up these dots at some point and build a complete open-source MRI research system that can be the basis for developing a medical device for use in clinics. There has been tremendous progress since then, and at the ISMRM in London in 2022, the first open-source low-field MRI prototype, the OSI² ONE v1, was presented. There is a large international group working on an upgrade of this first prototype into a robust, safe and well-documented reference scanner. This includes a lot of work around the process of regulatory approval, which will be shared as well, to create important blueprints that are currently lacking ( At the same time, we are in the process to found the NGO Open Source Imaging Initiative. In this official body, we have a better tool to support the community and implement many more ideas for our open-source medical technology vision. So, the future is looking very bright and the current and growing experiences, blueprints, and infrastructure in the making can be translated to many other complex projects in the domain of open-source medical device development. 

4. Are there any other reproducible research habits that you didn’t use for this paper but might be interested in trying in the future?

In the software domain, many tools, standards, and libraries exist to make life easier for an open-source project. As regards hardware, there is still some room for improvement and exploration. While we tried to share all the design files and significant checkpoints to ensure reproducibility for our paper, we acknowledge the need for further improvement in the documentation. Currently, we are actively working on a revised version of the hardware that will feature enhancements specifically tailored for manufacturing purposes. There are many other features that we consider useful and will try in the future such as: markdown-based documentation and automated scripting to help with versioning, but also other things like the generation and update of manuals, risk analysis etc., a map to track the location of reproduced designs, and test methods/scripts or videos of assembly and operation. Reflecting on past open-source projects, we have encountered challenges with obsolete parts. To mitigate this issue, we are trying to suggest alternative parts and encouraging feedback from the community. 


Notify of

Inline Feedbacks
View all comments