Everyone is talking about digitization, but what is actually behind it technically? I spoke with m.Doc Chief Technology Officer Osiris Roost about his job, data security and the level of digitization in healthcare. His answers are like good code: logical, concise, and absolutely comprehensible.u look now has the opportunity to shape digitization in German hospitals in a way that skips a few evolutionary steps.
Osiris, as developers you are almost constantly improving digital solutions – true to the motto “after the release is before the release.” What are the drivers behind this constant renewal of systems?
First of all, we have to distinguish between minor and major updates. Minor updates are small improvements in the system, for example of cosmetic or volatile errors that simply happen during programming. We are only human. And within a system with 500,000 lines of code, there is always work to be done. In comparison, major updates are in a completely different league. Above all, there are very different approaches and motivations here.
What would those be?
The most extreme example is certainly two development teams working in parallel. While one maintains the platform, the second team works on a new release. Once that is ready, say within two years, the teams switch. In other words, every two years the system is rebuilt from the ground up. Somewhat more common are strategic major updates, which align an existing system with new trends and developments that sometimes require completely new approaches. This is usually preceded by a change in philosophy or direction. New hardware can also be an occasion for a major update – in the healthcare sector, for example, new medical equipment. And then you have to remember that we developers are really never satisfied with our developments.
You have to elaborate on that, please: You deliver ready-made and coherent solutions and systems, don’t you?
To understand that, we need to dive into the process for a moment. I’ve been programming for about 30 years now, worked with numerous developers and on even more developments. In all that time, I really haven’t met anyone who, when they had a major release that they had worked on for a year or more, didn’t wish they could start all over again. This is simply because programming means building logical systems. To do this, we write technical documentation and draw architectures. At the beginning, however, we can only guess in which dimensions we will move in the end. Once we get there, the system is usually much larger than originally expected and that’s exactly when every developer says to himself “if I had known that before, I would have done it differently”. That doesn’t mean something doesn’t work or is immature. It just means that there is potential for improvement, which is why we are always kind of driven to leverage that potential.
You and your team here at m.Doc are currently working on a major release, namely the 7th generation of our Smart Health Platform. How much innovation goes into an update like this?
That always depends on the industry and the environment, and of course on how a company positions itself. In the case of m.Doc and the platform update, I would estimate that about 70 percent is innovation – which is simply because, as a digital healthcare pioneer, we are actively helping to shape the future of healthcare and the industry still offers a great deal of room for innovation. Wherever digitization is already further along – think of social media for example – real innovation is of course much more difficult.
Can you already reveal a few details about the 7th generation?
Details will remain under wraps until the release. But what I can say right now is this: Many of the innovations and new features have emerged from direct feedback from the numerous customers who are currently working with the 6th generation of our platform. A lot of input also came from the consulting environment, other stakeholders in the healthcare sector, and of course from the company itself. People work at m.Doc who, among other things, helped develop the first HIS systems and thus have over 30 years of experience with healthcare IT. Ultimately, all of this very constructive feedback has led to a large part of the code being renewed. So the (healthcare) world can really look forward to this major release.
How do you rate the topic of data, information and IT security, which is often the subject of controversial discussions, especially with regard to sensitive health data?
There is no such thing as absolute safety in any system. Aircraft are the safest means of transport, and yet some crash again and again. That’s why there are standards and guidelines for maximum security. From my point of view, it is clear that the current phase of digitization in healthcare is not one for amateurs. There is still too much at stake here – also in terms of acceptance. On the other hand, we cannot stop digitization. That’s why we can only design the systems as well and as securely as possible – and must work continuously on improvements.
In conclusion: Why do you think the healthcare sector in particular is not yet further ahead in terms of digitization compared to other industries?
I have a relatively simple and, for me, coherent explanation, which is related to the development of IT as a whole. It all started with some students who founded today’s tech giants in the various garages of Silicon Valley. In your early 20s, you have a lot of visions and ideas, but you don’t usually worry about your health. You take it for granted. But at some point, even tech visionaries and developers get older, have families and children. I recently had to take my son to the hospital and wait about two hours in the emergency room – and that’s short because I live in a country with good healthcare. Still, it’s experiences like this that are crying out for digitization. I should be able to log in at home, submit all the information, and then get a time slot at the nearest hospital. And that’s exactly what I’d like to work on with the m.Doc team – today, in my early 20s, my answer would probably have been different.