The emerging age of connected, digital world means that there are tons of data, distributed to various organizations and their databases. Since this data can be confidential in nature, it cannot always be openly shared in seek of artificial intelligence (AI) and machine learning (ML) solutions. Instead, we need integration mechanisms, analogous to integration patterns in information systems, to create multi-organization AI/ML systems. In this paper, we present two real-world cases. First, we study integration between two organizations in detail. Second, we address scaling of AI/ML to multi-organization context. The setup we assume is that of continuous deployment, often referred to DevOps in software development. When also ML components are deployed in a similar fashion, term MLOps is used. Towards the end of the paper, we list the main observations and draw some final conclusions. Finally, we propose some directions for future work.

Agile software development embraces change and manifests working software over comprehensive documentation and responding to change over following a plan. The ability to continuously release software has enabled a development approach where experimental features are put to use, and, if they stand the test of real use, they remain in production. Examples of such features include machine learning (ML) models, which are usually pre-trained, but can still evolve in production. However, many domains require more plan-driven approach to avoid hazard to environment and humans, and to mitigate risks in the process. In this paper, we start by presenting continuous software engineering practices in a regulated context, and then apply the results to the emerging practice of MLOps, or continuous delivery of ML features. Furthermore, as a practical contribution, we present a case study regarding Oravizio, first CE-certified medical software for assessing the risks of joint replacement surgeries. Towards the end of the paper, we also reflect the Oravizio experiences to MLOps in regulatory context.

Manufacturing of medical devices is strictly controlled by authorities, and manufacturers must conform to the regulatory requirements of the region in which a medical device is being marketed for use. In general, these requirements make no difference between the physical device, embedded software running inside a physical device. or software that constitutes the device in itself. As a result, standalone software with intended medical use is considered to be a medical device. Consequently, its development must meet the same requirements as the physical medical device manufacturing. This practice creates a unique challenge for organizations developing medical software. In this paper, we pinpoint a number of regulatory requirement mismatches between physical medical devices and standalone medical device software. The view is based on experiences from industry, from the development of all-software medical devices as well as from defining the manufacturing process so that it meets the regulatory requirements.Index Terms-Medical device software, medical software development, medical device standards, regulatory requirements, regulatory compliance• Union harmonized legislation (incl. essential requirements),• National legislation,• Harmonized standards,• Guidelines. EU harmonized legislation includes legal acts of directives and regulations. There is a significant difference between the two: regulations will enter into force directly in all member states, whereas directives define a specific set of objectives that member states must fulfill, for example, with national

Continuous software engineering has become commonplace in numerous fields. However, in regulating intensive sectors, where additional concerns need to be taken into account, it is often considered difficult to apply continuous development approaches, such as devops. In this paper, we present an approach for using pull requests as design controls, and apply this approach to machine learning in certified medical systems leveraging model cards, a novel technique developed to add explainability to machine learning systems, as a regulatory audit trail. The approach is demonstrated with an industrial system that we have used previously to show how medical systems can be developed in a continuous fashion.

No abstract