[Automatic captions by Autotekst using OpenAI Whisper V3. May contain recognition errors.] I will start by talking and then I will jump over to a demo afterwards.
The first thing I want to talk about is something that is a bit invisible when we do it right.
And unfortunately not invisible when we do it badly, and that is the stabilization of the service as a whole.
It is very important to have a service that is accessible.
Why should you say something about that?
Yes, because we have unfortunately had problems with the storage system and some networks from time to time.
And one could have said that yes, we have worked with that.
and we have been more stable and then done with it.
But I would like to dig a little more into what it means.
So I'm going to talk a little about what happens when you use DST.
You have a data machine that connects to a remote desktop via a fire wall.
And that virtual machine talks to a storage solution via the same fire wall.
The reason we have this fire wall is to ensure that the data is safe in the DST and in each project.
That you can't get hold of other data, but it can create problems.
I thought we could quickly talk through what is called the Internet Protocol to solve the problem.
In short,
you have to send data from one data machine to another data machine.
Let's say that the data you want to send is a setting like, this is some data.
What do you do with it?
You divide it up into smaller pieces until you have 0 and 1.
These are represented on a physical level by either electricity or light, whether you use fiber or not.
Then it goes from one machine to another.
But again, this ITSD goes through a fire wall.
And what happens if you get caught by one of these packages?
Then the whole setting does not come forward.
So the whole protocol is set up to be able to detect when these packages are lost, and then send them again.
And that's when problems occur, because then things have to wait.
Okay, the package hasn't arrived, I have to ask when I have to wait, I have to wait, and then suddenly your software doesn't work anymore.
And that's what we've been working on for quite a long time to get rid of.
Here you see a graph of lost packages on the fire wall.
We have seen that data traffic is lost from time to time.
It's not a problem in itself, because the protocol is designed to handle this, but sometimes the software can struggle with it.
And we have now fortunately managed to have the graph at zero for several months.
And that contributes to stability in the service as a whole.
So we have used a lot of energy and time on this.
As I said, this is work that is somewhat invisible, but extremely important.
On the storage side, we use a system made by IBM, and we have a very close dialogue with them.
To be able to understand problems, search for errors,
And we have also spent a lot of time on that.
And fortunately, the last thing we have is much better stability and the fire wall as well.
It is an open source code operating system called FreeBSD that we use.
Okay, now we're done with the internet protocol and the fire wall.
Now I'm just going to go through the larger collaboration projects that we are involved in.
Gart mentioned reuse of medical data.
At the EU level, the EU is now looking at establishing what is called the European Health Data Space.
It is a regulation that will mean what requirements there are for analysis, when you are going to share
Medicinal data across borders.
What do you need to do to be able to use Medicinal data from Sweden in your analysis room?
How are you going to ensure that?
And there we are in a project called Towards European Health Data Space.
And we are going to say from what we think, what is correct in relation to requirements.
The project that looks at this is a collaboration between Folkehelseinstituttet, E-Helse, Helsedirektoratet, Norsk Helsenet and many others.
The project is called Fair Secure Provision and Use of Health Data in Norway.
It's also a project called Ask and Trust that looks a bit like the Spuhinn project.
But here we are going to establish what we think of as a kind of blueprint for creating a trusted research environment.
So if you want to be part of this ecosystem, if you want to be able to provide an analysis room, how can you build this?
We have seen that in Norway we have
three different solutions to work with sensitive data.
We have TSD, in Bergen we have SAFe, and in Trondheim we have HuntCloud.
We want to collaborate and make it easier to use these three together.
So we have created a consortium called Nord3.
And when we participate in EU projects and talk to different departments, we now speak with one voice under Nord 3.
This is very good, because then we can be even more clear about what we think is right, and hopefully make it easier for the researchers.
For example, when they have some data that is in SAFe or HandCloud or TSD and want to move it, then we can maybe build these platforms further to be able to negotiate better.
The last point here is that the government has a strategy for personalized medicine.
What is happening here?
I'm a little unsure.
There are many plans, but one of the plans is to establish a national genome center where genome data can be stored.
This is a talk about clinics and research, but we know that clinics and research are closely linked.
It is now a project to find out what a national genome center should be.
They are part of the project to help with conceptualization and reality-oriented work.
What do people actually need when they are researching data?
And here we try to look at reuse of existing solutions, so that you don't throw the money away.
Single sign-on.
We know that you don't like to log in, so we will get rid of as many log-in prompts as possible.
So we want it so that you log in once for TSD as a whole.
So we work towards this.
Later we will show you the service called On Demand, which you find in EduCloud.
It is a web interface for high performance computing.
And we will also get that in TSD, so that you can use Colossus on PC without having to learn anything about the queue system.
You can fire up a net reader in your virtual machine in TSD and use known software as if it were on a desktop.
So then you can use powerful resources without having to learn anything.
That is very good, because then you can use more time on the research itself.
And now a short demo of new t-nests.
This is now in TSD, and I have opened a net reader.
It opens automatically on a start page called Start.
A very nice name that works in both English and Norwegian.
Start and Start.
I'm very happy with that.
Here you can find more information.
We will publish more information here in NEWS.
And a list of internal services.
In the future, we will have several services here.
You can see, for example, the network scheme portal.
I'm not going to show it now.
But it's very important that we've made it possible.
After ten years in operation, we finally have a start page that is automatically available.
I will show you a new service called Tables.
It is a very generic, Excel, Google Sheet-like TNST that we have launched for a project in collaboration with Nubu.
We use it as a kind of register tool.
They have a contact database with different families.
They collect a collection.
But it is a very generic interface against data.
We don't know how it can be useful for you, so we just put it in Prod.
You can use it, give feedback, say if it's something you want.
But to show you, you can have a table and then you can make changes.
And then you can say why.
And then you can look at all the changes.
What makes it different from Excel is that it has less functionality.
It's always like that.
We're not going to try to be Excel.
But what is very important here is traceability over all changes.
So here you see a change log for the table.
when the change has been made, who has done it, and very important, why you have made that change.
So if you have a collaboration where you have a lot of manual work, you have to control things and you have to know what has changed, why, and communicate in a team, then this can be a very useful tool.
And then you can have access control, for example, on which tables people can have access to.
This can be a kind of internal register tool in the long run.
Now I'm not in TSD anymore, I'm in my web browser on this machine, but I also have
I haven't used the TSD login, so I don't know what TSD is.
You have the inside and the outside.
So it's the TSD service that is available outside of TSD.
And it's called RISC.
Yes, still.
So it's a beta service, but it's a risk management tool.
So we're going to use it ourselves, and we think it can be useful for others as well.
So it's simply reuse of tables.
And here we have, it's not a real ROS, but it's a ROS tool.
And again,
What is extremely important is that you can look at a risk element and what has changed and why.
And here you have an extremely good data basis for making decisions when you do risk assessments.
Because you store changes, you can have a time series.
over risk elements.
You can ask questions.
How is the risk profile today compared to last year?
At the same time, has it improved?
Why?
And so on.
From a developer perspective, you can link to a specific risk element.
So when you develop, when we develop, when you maybe develop something, and you make a code change that is directed towards
You can use this link in your pull request.
Here comes a change.
I will try to set something that has something to do with this risk.
We will go away from Excel and have tools that can be integrated with our workday.
If you have projects that require ROS analyses, this can be something for you as well.
If you have a TSD project, you can use it automatically.
First of all,
So if you have projects that need a ROSE-analysis... There are a lot of projects that need a ROSE-analysis.
I have to dig a little deeper.
There is a system for ROSE-analyses that is on its way?
Or has it been launched?
It was launched just for us, but it's in full production.
The only thing we need to do is make it available for other projects.
Now you can't log in with other TSD projects, but we have already started.
Yes, so it will be an internal ROS tool for us who work with TSD, but we expect that this will be a general ROS tool for everyone who uses TSD.
Yes, and for everyone who needs ROS analyzers.
Most people have to.
But we hate using Excel for our work.
It's just files floating around and no one knows where they are, and which file is the one to use.
So we want to get rid of that.
And we think that if we manage to take this into use ourselves, then it must be useful for others as well.
Yes, so we'll just have to wait and see.
This will come more and more in the future, as we will offer this for broader use, but we have created an advanced risk and safety analysis tool that we have already used.
But there was a question up there.
I was wondering about the table service you showed.
Could it have an API, so you can contact it with scripts, because then it can be safe?
I would have said that, of course it has an API.
Everything is API-based, so you can get access to it, create your own boundary, if you are not satisfied or need more functionality, of course.
The same goes for risk control tools.
There is also an API under there, so you can get all the data out and do your own analyses.
You can also load TSV files, or do you have to correct the table from scratch?
Yes, it is possible.
We are working on how to describe datasets.
I see.
Thank you.
More questions for Leon?
That people now can get more access to the data via APIs is a big change in the last few years.
Yes.