Interoperability Standards for Medical Device Integration in the OR

The Digital Operating Room

Advances in medical technology, specifically information technology (IT), in the last quarter of the 20th Century have produced extraordinary changes in the way medicine, and in particular surgery, is practised. These advances have not been without certain drawbacks and shortcomings, including escalating healthcare costs and the challenge of handling the complexity of these technologies.

It has been challenging to cost-justify many of the new technological and system advances, associated interventional procedures and the corresponding redesign of healthcare infrastructures, for example, for the Operating Room (OR). The development and dissemination of these technologies have become central issues in the debate over healthcare reform and healthcare finance.

 
Figure 1. DOR Maturity Levels

In particular, a number of major technical and organisational challenges are being faced in the attempt to improve the safety and effectiveness of connectivity/ interoperability for the diverse array of medical devices and information technology that proliferates in the OR environments today. These have been clearly identified in recent years, for example by J. M. goldman, MD, (Director, CIMIT Program on Interoperability, and Medical Device “Plug-and-Play” Interoperability Program), as challenges in their MD PnP Program (goldman 2007):

• Proprietary medical device systems; long capital equipment cycles (12 years!);

• Limited comprehensive, vetted user requirements (clinically/safety-based);

• Absence of proven standards matched to clinical requirements;

• Tendency to silo standards that would limit interoperability across continuum of care;

• Limited funding for development;

• Limited recognition of complexity of challenges in IT-BME convergence and lack of system; integrators to build the middleware;

• Legal (liability) concerns;

• Regulatory pathway questions.

In the current MD PnP Program (MD PnP Program 2014) it is interesting to note, that user requirements in the program are established by means of explicit clinical scenarios – i.e. workflow analysis of clinical scenarios at a level of detail needed to create the basis of interoperability solutions and to derive engineering requirements.

In the context of international approval procedures and, relating to the challenge of “Regulatory Pathway” transparency and reduced complexity, the MD PnP Program is leading a working group of companies, academics, and hospitals that are developing a prototype regulatory submission to help refine the FDA clearance process (see FDA workshop content (U.S. Food and Drug Administration; Continua Health Alliance; Center For Integration Of Medicine & Innovative Technology (CIMIT); Medical Device “Plug-and-Play” Interoperability Program (MD PnP) 2010)).

To move beyond conceptual demonstrations of new interventional systems and towards the systematic assessment and employment in interventional settings, an understanding of the expected maturity levels of the Digital Operating Room (DOR) at present and in the foreseeable future is helpful (Lemke and Berliner 2011).

Figure 1 provides an estimated timetable for the past, present and future developments of the DOR over a 25-year period including:

• its development up to the present time as well as its continued development and implementation

• the political, economic, and industrial issues that may be encountered (Lemke and Berliner 2011).

Four main areas of technology development for the DOR can be identified:

1. Devices, including signal detection and recording, robotics, guidance systems, simulation technologies, which allow precision in the delivery of personalised operative healthcare;

2. IT Infrastructure, including DICOM, IHE, EMR, Therapy Imaging and Model Management System (TIMMS) infrastructure for the storage, integration, processing and transmission of patient specific data;

3. Functionalities, including specific interventional processes, patientspecific modelling, optimisation of surgical workflow, TIMMS engines and;

4. Visualisation, including the processing, transmission, display and storage of radiographic images, video, and physiologic signals (e.g. a type of surgical PACS).

Each of these areas is following its own characteristic development, validation and approval cycle and methods. In (Lemke and Berliner 2011), five stages of maturity for the various technical areas have been identified in the development of the Digital Operating Room for the first quarter of the 21st century:

2005+: Maturity level 1

Characterised by the vendor-specific integration of technologies. The critical feature of this stage is considered to be the development of integrated device control. Additional technologies include high definition (HD) video and digital image acquisition and processing, boommounted devices, automatic reporting.

2010+: Maturity level 2

Characterised by perioperative processes optimisation. The two critical features of this stage are considered to be the development of preoperative image integration and navigated control. Additional technologies include basic DICOM in surgery, intraoperative image acquisition, modelling and simulation and intelligent cameras.

2015+: Maturity level 3

Characterised by intra operative process optimisation. The two critical features of this stage are considered to be the development of a workflow management (TIMMS) engine and full DICOM in surgery. Additional technologies include DOR process redesign with EMR and signal integration, basic IHE integration profiles for surgery, smart walls including n-dimensional visualisation, and basic model-guided intervention.

2020+: Maturity level 4

Characterised by vendor-independent integration of technologies. The critical features of this stage are considered to be the development of hospital/enterprise wide interoperability and patient specific models. Additional technologies include knowledge and decision management, clinical quantitative and statistical assessment, and IHE integration profiles for surgery, pathology and interventional procedures generally.

2025+: Maturity level 5

Characterised by intelligent infrastructure and processes. The critical feature of this stage is considered to be the development of surgical cockpit systems and Medical TIMMS architecture. Additional technologies include real-time access to peerto-peer surgical process repositories, intelligent real-time data mining, full voice/gesture control, real-time CAD integration, and intelligent (situation aware) robotic devices.

A glimpse of what may be ahead in the OR and predicted in (Lemke and Berliner 2011) is provided by an interesting example of a surgical workflow management system, which includes a Surgical Procedure Manager (SPM), already in clinical use at the International Development Reference Centre (IRDC) in Leipzig (Strauß et al. 2013).

First experiences with this system show that this type of knowledge-based system in the OR can improve efficiency of the interventional processes. It may, however, induce the surgeon to rely excessively on the “intelligence” of the machine to provide the “right” information on patient and processes at the right place, at the right time and to the right person in the OR.

Trust in this form of “intelligence” and in the right record-keeping and subsequent management of interventional process information for patient outcome evaluation, are new dimensions of concern when machine intelligence moves into therapeutic activities within the context of a digital OR.

Important aspects of these dramatically evolving ICT based methodologies and tools are new requirements for:

1. DOR IT architectures providing the right basis for enabling a higher quality of therapeutic interventions by means of interoperability features, for example, real-time integration of information in patient related data structures and therapeutic processes through computer assisted workflow, knowledge and decision management (see also section 2 below).

2. Standards that take account of the specific requirements for surgical/ interventional workflows, devices and systems. Examples are DICOM in Surgery and IHE Surgery (see also section 3 below).

3. Methods and tools for supporting approval procedures on an international level, for example, device/ systems classification, clinical and non-clinical testing for safety, high confidence medical device software and systems through appropriate modelling and simulation, etc. (see also section 4 below).

2. DOR IT architectures for interoperability

Architectural features, for example, as part of an intelligent infrastructure of an OR have only recently become a focus in discussions relating to interventional settings (goldman 2007; Lemke and Vannier 2006). Such an IT reference architecture may be referred to as a Therapy Imaging and Model Management System (TIMMS) (Lemke and Vannier 2006).

A TIMMS-like architecture and its application for achieving image and model guided therapy has been the subject of discussions i n t he DICOM and I HE standard activities. An implementation of a prototype based on open standards of the modular TIMMS-like architecture is in progress at the Innovation Centre Computer Assisted Surgery (ICCAS) in Leipzig, germany. TIMMS is a comprehensive medical-surgical communication and assistance system (see Figure 3), which is composed of interconnected computer hardware and software components (such as engines, repositories and an IT infrastructure).

There are seven TIMMS engines, which may be defined as software modules which can be executed on an appropriate computing machine in order to provide interventional functionalities. These engines relate to imaging and biosensor data acquisition, modeling, simulation, workflow and knowledge and decision management, visualisation, intervention and validation. Some of these engines are already present and used in modern OR systems.

The Kernel for workflow and knowledge and decision management provides the strategic intelligence for therapeutic planning and workflow execution. Often this module (or parts thereof) is integrated into some of the other engines, as need may demand. This important computing kernel (or “brain”) of the system may use different forms of logic, different database structuring, agents and other forms of artificial intelligence, depending on the specific applications of the performed procedure.

In a full realisation, a TIMMS may provide the following features and functions throughout the course of a medical and surgical treatment:

1. Standardised interfaces for communication and mechatronics, thereby creating a unified environment for the input and output of data (including the representation of and display of information and images, as well as the electromechanical control of surgical and navigational devices);

2. Creation and maintenance of a patient-specific model (PSM), thereby providing a multi-scalar, comprehensive, precise, personalised representation of the patient;

3. Creation and maintenance of a system for process modelling (PM) of all aspects of the surgical workflow, to ensure efficiency, learning and safety throughout operative procedures;

4. Real-time knowledge management and decision support system thereby promoting optimised diagnostic, prognostic and therapeutic decisions throughout the treatment workflow;

5. Validation and approval procedures, thereby providing quality assurance, patient safety, system security and processing of medical evidence towards securing better patient outcome.

Features 1, 2, 3 and 4 are the prerequisite of an intelligent infrastructure of an OR. A full realisation of these functions is still a long way away. In practice, however, some small subsets of patient models, process models and/or real time knowledge management have been implemented and clinically tested. Feature 5 can begin to be properly addressed when features 1-4 have reached a tangible stage of implementation from which one can derive appropriate requirements for safety testing and feature/(usage) classification for devices and systems approval.

Feature 2 is subject to standard activities in working groups in DICOM and IHE in surgery. Feature 5 is of major concern in a number of regulation agencies such as FDA, PMDA, CEN and DIN. FDA and PMDA will be discussed further in section 4 below.

One of the architectures proposed in OR:NET (OR.NET 2014) is somewhat different in appearance with respect to the TIMMS architecture, but conceptually contains an equivalent base structure (see Figure 4).

3. DOR standards

Since 2003/2004 it was recognised (Lemke et al. 2005; CAR/CMI 2004), that the realisation of the “OR of the Future” or DOR, will be a comprehensive undertaking, requiring, among others, the development of standards for achieving interoperability of medical devices and systems in the OR. Since then, DICOM and IHE have been considered, in principle, as enablers for fulfilling these requirements.

3.1 DICOM in Surgery

DICOM in Surgery, i.e. the DICOM Working group 24 was founded in 2005 with the aim of developing DICOM objects and services related to image-guided surgery (IgS) and related interventions. Its initial roadmap included:

• Select and define a user community of IgS disciplines in Wg24. Initially five surgical disciplines (Neuro, ENT, orthopedics, cardiovascular, thoraco abdominal) and interventional radiology have been selected. Anaesthesia is included as long as surgery is affected.

• Compile a representative set of surgical workflows (with a suitable high level of granularity and appropriate workflow modelling standards and surgical ontologies) as a work reference for the scope of Wg24. Initially, 3-5 workflows, characteristic for each discipline, should be recorded with sufficient level of detail.

Derive potential DICOM services from these surgical workflows and identify appropriate use cases.

Design an information model based on electronic medical record (EMR) and related work on patient modelling to identify IOD (Information Object Definition) extensions for DICOM.

Take account of the special image communication (1D - 5D) requirements for surgery and mechatronic devices. A close cooperation with other Working groups should be pursued.

Connect to integration profiles specified in existing IHE domains. In close cooperation with industry a number of DICOM supplements have been realised in recent years.

Supplement 132- Surface Segmentation

This IOD can be used to encode tissue segmentation, functional segmentation, and artefact identification for quantification or visualisation.

Supplement 131- Implant Template

This supplement describes storage, query and retrieval of implant templates (generally non-patient-specific) as they are used in implantation planning.

Supplement 134 - Implantation Plan

The aim of this supplement is to communicate implantation planning information from the planning workstation to the operating room.

Supplement 154 - Optical Surface Scanner

This supplement introduces a modality for optical surface scanners. This allows storage and retrieval of scanned surfaces to and from a PACS. Some IgS and DOR related problems are currently under discussion in Wg 24 that could lead to work items.

A Universal Reference Coordinate Standard which helps to freely transfer spatial information between involved devices and systems pre- and intraoperatively;

A standardised way to communicate patient identity to participating devices in the OR. Wg 24 is open f or discussion for other potential work items, in particular those which may be indentified, for example, in projects such as OR.NET and MD PnP.

3.2 IHE Surgery

IHE Surgery was founded in 2012 as a provisional IHE domain (IHE International Board 2012) after a long preparatory phase by the sponsoring organisations, the International Foundation of CARS and the International Society for Computer Aided Surgery. The scope and rationality of the domain include:

• The IHE Surgery domain addresses the problems of interoperability, information sharing, and model sharing to improve the quality of care in surgery and related interventional therapies. It focuses on the needs for Image and Model guided Therapy (IMgT) Systems.

• The solutions for the interoperability problems in the field of surgery and related interventional therapies are not yet on the level of the solutions presented in the IHE profiles of other IHE domains. Since surgery is one of the core units in a clinical setting, it is therefore important that it is represented as an IHE Domain.

Some of the needs in the context of the DOR that are currently being addressed are:

• Distribution of implant templates for surgeons, applications, and surgical devices

• Distribution of implantation plan through the preoperative, intraoperative, and postoperative phase.

• Creating, storing, and retrieval of surface segmentations.

• Creating, storing, and retrieval of surface scanner objects.

• Intra- and inter-institutional distribution of surgical process models.

• Intra- and inter-institutional distribution of digital patient models.

Of particular interest for IHE Surgery are the potential integration profiles or clinical story boards from the clinical domains of ENT, laparoscopic, spinal surgery and anaesthesia currently being investigated for the OR.NET Demonstrators and which are expected to be implemented in the last phase of the OR.NET project.

This would support the recommendation expressed in (Moser et al. 2013), which envisages a strong role for IHE Surgery in transcribing OR.NET use cases (after they have been prioritised and consolidated) into IHE use cases / Integration Profiles (IP) in a move towards a closer cooperation between OR.NET and IHE Surgery, generally.

4. International approval issues

A critical question for the development of IT architectures and standards which support interoperability in the OR, relates to the issues they raise in risk assessment and the appropriate classification by the international approval processes for medical devices and systems.

In the following, the current situation of approval procedures in the USA and Japan will be briefly outlined (in a follow-up publication they will be compared to regulatory developments in Europe). Most of these observations are based on presentation and discussions in the course of a CARS 2014 DICOM in Surgery and IHE Surger y Workshop on “DICOM Supplements and IHE Integration Profiles, Implementation and Approval Issues”, which took place in Fukuoka, Japan on June 28, 2014.

4.1 FDA (USA)

It appears that the FDA is taking an active role in the discussion relating to interoperability and corresponding issues in approval regulations by also being a member of the MD PnP project (goldman 2007).

Support for MD PnP program work has come from DoD/TATRC, NSF, NIST, CIMIT, and NIH/NIBIB, which awarded a $10M Quantum grant in October 2010 to develop a healthcare intranet based on integrated medical device systems.

An important part of the key MD PnP Program p rojects i s ( MD P nP P rogram 2014) “Defining a safe regulatory pathway for patient-centric networked medical devices.” Carried out in close partnership with the FDA, progress so far includes a co-sponsored workshop held by FDA in January 2010 on medical device interoperability, followed by a working group of companies, academics, and hospitals that have developed and submitted a pre IDE (Investigational Device Exemption) regulatory submission to help refine the FDA clearance process.

Some of the questions posed by representatives from FDA include (U.S. Food and Drug Administration; Continua Health Alliance; Center For Integration Of Medicine & Innovative Technology (CIMIT); Medical Device “Plug-and-Play” Interoperability Program (MD PnP) 2010):

Clinical issues

What clinical scenarios could make use of medical device interoperability? Are there clinical scenarios that would not be appropriate?

Engineering issues

How should medical device interoperability be defined in terms of architecture, components, interfaces, functional requirements and performance requirements?

Risk issues

What are the risks associated with medical device interoperability and systems of systems composing medical devices? Use of risk models for interoperable systems.

Management issues

Who are the responsible parties and what is their role in design, building, maintenance, improvement as well as development and dissemination of standards and best practices?

It is interesting to note, that the FDA is responding positively to 510(k) applications, which include in their device description compliance to IHE, DICOM and HL7. For an example see (U.S. Food and Drug Administration (2011), which refers to a recent PACS approval procedure by a major manufacturer who included in its device description:

“Centricity PACS is a standards-based, customisable, and scalable solution supporting several of the Integrating the Healthcare Enterprise (IHE) profiles, Digital Imaging and Communications in Medicine (DICOM), and the Health Level Seven (HL7) protocol standards for managing digital medical images and patient data. Centricity PACS supports radiographic imaging-as in clinical radiography, cardiology, dentistry, and mammography and non-radiologic imaging, including video support”.

Also in the area of PACS components or devices it can be observed that compliance to IHE integration profiles is thought to be a significant advantage in FDA approval procedures. For example, Three Palm Software, LLC stated in their application (U.S. Food and Drug Administration 2007):

“The enterprise workflow of the workstation (WorkstationOneT M Breast Imaging Workstation) follows IHE integration profiles, specifically, MAMMO (Mammography Image Profile) and RWP (Reporting Workflow Profile)”.

Another example of FDA approval applications with IHE integration profiles is in the area of digital radiography software tools for Quality Assessment (QA), in particular “Standardised Dose Reporting for QA” (Don 2012). The Alliance for Radiation Safety in Pediatric Imaging recommends the IHE Radiation Exposure Monitoring (REM) profiles and DICOM Structured Reports (SR) to be applied in this context.

For approval purposes, medical devices and systems, such as given above need to be grouped into one of three FDA regulatory classes: Class I, II or III, depending upon the degree of regulation necessary to provide reasonable assurance of their safety and effectiveness.

The three device classes are defined as follows (U.S. Food and Drug Administration 2014):

Class I: Devices are subject to a comprehensive set of regulatory authorities called general controls that are applicable to all classes of devices.

Class II: Devices for which general controls, by themselves, are insufficient to provide reasonable assurance of the safety and effectiveness of the device, and for which there is sufficient information to establish special controls to provide such assurance.

Class III: Devices for which general controls, by themselves, are insufficient and for which there is insufficient information to establish special controls to provide reasonable assurance of the safety and effectiveness of the device. Class III devices typically require premarket approval.

Most medical devices can be classified by finding the matching description of the device in Title 21 of the Code of Federal Regulations (CFR), Parts 862-892. FDA has classified and described over 1,700 distinct types of devices and organised them in the CFR into medical specialty panels such as Cardiovascular devices or Ear, Nose, and Throat devices. The devices most relevant for the OR can be found in Part 878 entitled general and Plastic Surgery, Part 876 entitled gastroenterology-Urology Devices and in Part 892 entitled Radiology.

There is a comprehensive set of guidelines on how to apply for FDA Premarket Approval (PMA) or premarket notification (often referred to as a 510(k). This is particularly the case also when there is software contained in medical devices (U.S. Food and Drug Administration 2002).

An approval application is usually supported by a list of standards, which the medical device/system has been shown in tests to be in compliance with. Most of the well-known national and international standard bodies are explicitly recognised by the FDA. This list does not include IHE (as IHE is not a standardisation organisation) but examples o f FDA approval application demonstrate that IHE compliance is being used in the device descriptions as a marker for quality. How the importance of compliance with IHE integration profiles is being rated in the approval process, however, is not made clear by the FDA guidelines for Industry or by Food and Drug Administration Staff.

A very special situation exists for an approval application for an IDE, relating to clinical trial approval by foreign companies. In this case, the sponsor of the clinical trial is responsible for submitting the IDE application to the FDA (§812.40) and obtaining Institutional Review Board (IRB) approval before the study can begin. Foreign companies wanting to conduct a clinical study in the U.S. MUST have a U.S. sponsor (§812.18).

4.2 PMDA (JAPAN)

The Pharmaceuticals and Medical Devices Agency (PMDA) is the FDA equivalent agency for approval procedures for medical and surgical devices and systems in Japan. In principle, it can be observed, that the medical device approval procedure is harmonised with those of other advanced countries.

Figure 5 shows the classification used by PMDA, in principle derived from activities of the gHTF (global Harmonisation Task Force) (USA, EU, Australia, Canada, and Japan). It is (almost) in line with respect to the FDA classification, except that an extra Class IV has been added for highly risky devices. For Class II devices, third party certifiers (in EU terminology: notified bodies) are approved by the Minister of Health, Labor and Welfare (MHLW). The approval criteria, however, are defined by MHLW. It is expected that after November 26, 2014 third-party certifiers will also be permitted to review and approve Class III devices.

As regards approval for software, it is important to note that high-risk health software running on non medical devices will be regulated after Autumn 2014. Specifically, software operated in nonmedical devices (such as PC and tablet) used for high-risk applications will be reviewed by PMDA also after autumn, 2014. It can be expected, that the safety requirement defined in international standards will be referred to. Surgical navigation software running on conventional PC will also be regulated.

An important point of discussion in Japan relates also to the question whether the clinical data obtained in foreign countries is applicable to the review process in Japan.

Specific issues are:

• clinical environment,

• differences in anatomy, pathology, depending on race, etc.,

• comparison with standard care.

In general, the PMDA profile of services as indicated in the 6 phases (top of Fig. 6), i.e. Research and development, Non-clinical tests, Clinical Test, Filing of application, Approval and Marketing, are similar to the FDA and European approval services. It is important to note that standards development is considered to be a continuous activity in the PMDA profile of services.

It is also recognised by PMDA that, in order to improve on the profile of services (Pharmaceuticals and Medical Devices Agency, Japan 2013), a promotion of regulatory sciences is important to accelerate R&D of medical devices as well as an enhanced international cooperation. PMDA, therefore actively promotes international activities in line with the PMDA International Strategic Plan and the International Vision formulated in 2009 and 2011, and as well as a road map for more specific action plans defined in 2013.

In order to build closer relationships with the EU and the US, PMDA has dispatched its staff members to regulatory agencies abroad including the European Medicines Agency. Moreover, PMDA’s ties with other regulators from the US, Europe, and Asia have been reinforced by means of holding PMDA training seminars and the exchange of trainees.

5. Conclusion

5.1 Observations and Questions

A significant number of functionalities in the Operating Room require (real-time) exchange of data and control information. Based on the IT architectures discussed above and generic standard issues outlined in a Weissbuch on “Sichere Dynamische Vernetzung in Operationssaal und Klinik” (Moser et al. 2013), these functionalities may best be understood by means of clinical scenarios or use cases which address real clinical requirements for interoperability. Approval of devices and systems, which claim to have features to support such interoperability should be based on tests, which include compliance to standards. This, however, poses a number of questions which need to be addressed in the development of the DOR

These include:

1. What functionality/feature changes to an already approved device distinguishes a predicate device 510(k) procedure from a new or post-predicate device (for example, augmented with new interoperability features), ie when and when not is a device substantially equivalent to a predicate device and does it need to be classified as Class

3 requiring something similar to a Premarket Approval?

2. How will specific software (including for example, new Apps) for “intelligent” or web-enabled interoperability be classified in Japan, USA or Europe (taking into account the differences in device classification systems)?

3. What strategic steps in national and international approval organisations and technical and legal developments are necessary to raise the importance of IHE Connectathon and certification, as a basis for safety assessment in the approval process?

4. What strategic steps in national and international approval organisations and technical and legal developments are necessary to raise the importance of a scientific approach, as a basis for safety assessment in the approval process?

Another interesting observation relates to the classification of medical devices, which perhaps will become a major issue comparing FDA, PMDA and corresponding EU Directives. The latter states (Council directive 2007):

“Where a Member State considers that the classification rules set out in Annex IX require adaptation in the light of technical progress and any information which becomes available under the information system provided for in Article 10, it may submit a duly substantiated request to the Commission and ask it to take the necessary measures for adaptation of classification rules. The measures designed to amend non-essential elements of this Directive relating to adaptation of classification rules shall be adopted in accordance with the regulatory procedure with scrutiny referred to in Article 7(3).”

The question here to be addressed in the future relates to whether devices augmented with (intelligent) software for interoperability qualify for the label “technical progress” and may therefore require, for an appropriate classification, an adaptation of the classification rules as given by the regulatory agencies. It remains to be seen, whether the new drafts for Amendments of the EU Directives concerning medical devices or the expected new PMDA regulations will take account of these new technological challenges.

5.2 Recommendations

It can be expected, that the complexity of the clinical and non-clinical tests for safety is very high, and a solid scientific foundation (Pace 2004) is necessary to show that a safe interoperability has been achieved. The PMDA drive to promote regulatory sciences is important in this context and may be of particular significance when devices and systems are planned to be employed in an international environment. From this and the observations made above, a number of recommendations can be derived:

1. In the middle or long term a Centre for interoperability in the OR with a strong focus on scientific methods and tools may have to be established on an international level, not least to establish completeness and reproducibility of testing procedures for clinical and non-clinical tests for interoperability of medical devices and systems for the OR, thereby enabling a higher confidence level for safety of medical device software and systems in the OR (Lee et al. 2006).

2. As it is expected that the role of IHE integration profiles will increase in importance for approval agencies in the future, IHE generally and IHE Surgery Connectathons specifically, can be considered to be the first steps in this direction and should become a focus of OR.NET, MD PnP and similar (follow-up) projects in the near future.

3. Leading industry for integrated Ors should be encouraged to take an active role in promoting activities

towards recommendations 1 and 2. This does imply In particular, taking steps towards the definition of a set of promising IHE integration profiles, which may then provide the basis for work items in the appropriate IHE domains.

4. A regular annual international OR interoperability forum for the exchange of views, concepts, R&D results, clinical and non-clinical safety testing, classification standards to facilitate conformity and predicate device testing, technical documentation, quality assessment and control of notified bodies, regulatory developments, etc. should be established. This forum should be of particular interest to SMEs engaging in the development of medical devices, in order to obtain a better understanding of resources required to achieve medical device approval on a national and international level. The CARS 2014 Workshop on “IHE Integration Profiles, Implementation and Approval Issues” (CARS 2014) may serve as a template for such a forum.

Acknowledgement

The lecture contributions to the CARS 2014 workshops relating to IHE and approval issues, etc. by Prof. Ichiro Sakuma, the University of Tokyo, Japan and Prof. Kevin Cleary, the Children Medical Centre, Washington DC, USA as well as discussion contributions by over 20 international participants have been very much appreciated.