IN VITRO DIAGNOSTICS: CAPITA EXOTICA

Transcription

1 IN VITRO DIAGNOSTICS: CAPITA EXOTICA Axon IVD seminar 12 September 2012 Erik Vollebregt orphan subjects that will soon develop to full-blown issues Stand alone software Data protection / privacy / data concerning health 1

2 Data protection Data protection revision: what s on the table? Current proposal is politically controversial and attacked from many sides, so outcome and timing unpredictable Definition of core concepts of data concerning health and genetic data also includes non-individualised data Processing of health data: exemptions for processing of health data narrowly drafted and available for medical treatment / provision of care scenarios under medical secrecy or equivalent secrecy obligation (art. 81) scientific, statistical or historic research purposes only with implementation of measures to anonymise data (art. 81 and 83) 2

3 Data protection revision: consent problematic Under currently proposed rules it will be more or less impossible obtain legally valid consent for processing of health data for telehealth services consent must be freely given, informed, specific and explicit (which makes it very difficult to account for future changes to service) controller has burden of proving that the data subject has given the consent to the processing operation Member states have different formalities consent is not a valid legal ground for the processing of personal data, where there is a clear imbalance between the data subject and the controller likely: HCP / patient relation public authority obligation (patient must use telehealth service and consent to processing) WP131 says consent not freely given Data subject rights and privacy by design Right to be forgotten can wreak havoc on clinical studies, registries and other data collection for meeting regulatory obligations Commission must be lobbied to provide delegated act for ehealth and medical devices sector ex art. 17 (9) that allows specific derogations on exercise of right to be forgotten Technical and organisational measures (privacy by design) (art. 23 (3)) as well as security (art. 30 (3)) may be subject of delegated act by sector / service Opportunity to lobby for uniform standards in EU EU-US data export requirements will essentially stay the same (consent, adequacy finding, SCCs, BCRs) 3

4 Organizational and logistic implications Health data processing will require impact assessment (Article 33 (2) (b)) to address the specific risks Impact assessment may be regulated by delegated act by European Commission and be part of prior consultation / authorisation from authorities for processing Large companies must have data protection officer Large fines for non-compliance : up to EUR or, in case of an enterprise up to 2 % of its annual worldwide turnover, to anyone who, intentionally or negligently: (a) processes personal data without any or sufficient legal basis for the processing or does not comply with the conditions for consent; (b) processes special categories of data in violation of Articles 9 (requirements health data) and 81 (exemptions health data) Impact on value chain of telemedicine Privacy-by-design requirements will impact entire value chain of a particular data stream Impact assessment must include entire model for a service and will be done on national level (no deadlines prescribed) Processors will have more independent regulatory responsibilities and run exposure for supervision and fines Health data processing exemptions will not apply to many ehealth models currently envisaged consent will be necessary but difficult to manage in practice if business model develops friction with regulators guaranteed 4

5 Opportunities for industry EU data protection law will be stricter and contain additional regulatory burdens, but may also offer new important opportunities for representative organisations Certification of level of protection regarding data processing under industry provided mechanisms and seals/marks (e.g. like Eucomed /EDMA mark), Commission can adopt measure (art. 39) Commission may decide that a third country, or a territory or a processing sector within that third country, or an international organization that ensures an adequate level of protection for data export (art. 41 (3)) (e.g. HIPAA certified compliance adequate level) Member states can bless self-regulatory code and declare it in conformity with Regulation (art. 38 (2)) ; Commission may declare general validity in EU for a code (art. 38 (4)). Data protection revision Additional burdens Opportunities Consent criteria will become stricter consent to processing separate from consent to treatment Additional administrative requirements for processor (documentation of processing, security, data breach information) Health data procession will require impact assessment Right to be forgotten difficult to implement unsure how this will play out in health data sets Penalties / remedies increased substantially (2% of annual WW turnover for health data) Certification of data protection policies through organisations like Eucomed / EDMA Adequacy findings for sectors in 3 rd countries HIPAA possibility but not widely coined as such yet More flexible Binding Corporate Clauses (BRC) regime More uniform approach to health data processing 5

6 Software Software as IVD any medical device which is a reagent, reagent product, calibrator, control material, kit, instrument, apparatus, equipment, or system, whether used alone or in combination, intended by the manufacturer to be used in vitro for the examination of specimens, including blood and tissue donations, derived from the human body, solely or principally for the purpose of providing information: concerning a physiological or pathological state, or concerning a congenital abnormality, or to determine the safety and compatibility with potential recipients, or to monitor therapeutic measures Accessory rule: stand alone software intended specifically by its manufacturer to be used together with an IVD medical device to enable that device to be used in accordance with its intended purpose 6

7 What flavours are there in the EU? Software falls in one of the below categories: Standalone medical device or accessory to medical device to be CE marked as such (e.g. diagnostic PACS add-ons) Component of medical device to be CE marked as part of the device (e.g. firmware of infusion pump) None of the above out of scope of the MDD (e.g. admin software, software design tools, general lab software) Software requirements and life cycle Defines manufacturer processes for life cycle of device Risk based compliance structure + risk management additional to device risk management requirements for each stage of the development lifecycle minimum activities and tasks to be performed each stage, depending on risk class of software 7

8 Software life cycle under EN62304 (1) Software life cycle under EN62304 (2) 8

9 MEDDEV on stand alone software Released January 2012: MEDDEV 2.1/6 Rev. 1 Guidelines on the qualification and classification of stand alone software used in healthcare within the regulatory framework of medical devices Only deciding criterion whether software is regulated will be its intended purpose (article 2 (1) (h) MDD): the use for which the device is intended according to the data supplied by the manufacturer on the labeling, in the instructions and/or in promotional materials So, stand alone software fulfilling the definition of medical device and intended to be used for the purpose of providing information derived from in vitro examination of a specimen derived from the human body falls under Directive 98/79/EC MEDDEV on standalone software Contains Decision trees for general standalone software en IVD standalone software Classification guidelines Guidance on modules Many examples 9

10 MEDDEV decision tree general Software decision tree under MDD; apply first to determine if in scope of medical device MEDDEV decision tree IVDs IVD software decision tree under IVDD; apply to determine if in scope of IVDD 10

11 MEDDEV decision tree IVDs Some remarks on data sources, data destinations and software Not IVD is stand alone software that: 1. collects only results obtained from one or several IVD devices (directly and/or manually), and transmits this without modification to a centralised database (e.g. LIMS) or to healthcare providers 2. manages the feed-back to an IVD (e.g. retesting of samples) based on collected IVD results (e.g. LIMS) 3. is intended to modify the representation of available IVD results (per decision step 5 in MDD tree) (e.g. basic operations of arithmetic (e.g. mean, conversion of units) and/or plotting of results in function of time, and/or a comparison of the result to the limits of acceptance set by the user) 4. is intended for archiving patient results or for transferring results from the home environment to the healthcare provider MEDDEV on concrete IVD examples lab software Not IVDs are: Laboratory Information Systems (LIS) Work Area Managers (WAM) But they may become medical devices if combined with modules with regulated functionality 11

12 MEDDEV on concrete IVD examples expert systems (1) IVD if intended to capture and analyze together several results obtained for one patient by one or more IVD devices by means of in vitro examination of body samples to provide information falling within the definition of an IVD medical device, e.g. differential diagnosis prediction of the risks of developing a disease prediction of the percentage of efficiency or failure (e.g. of a treatment) identifying species of bacteria MEDDEV on concrete IVD examples expert systems (2) Positively IVD are expert systems that: integrate genotype of multiple genes to predict risk of developing a disease or medical condition use an algorithm to characterize viral resistances to various drugs, based on a nucleotide sequence generated by genotyping assays (serves to generate new information (virus resistance profile) from available information on the genotype of the virus) are software intended to be used in microbiology for the identification of clinical isolates and/or the detection antimicrobial resistances 12

13 MEDDEV on concrete IVD examples - rendering If software is necessary to render raw data, obtained from an IVD by means of in vitro examination of body samples, readable for the user, this software is to be considered as an accessory to an IVD when it is specifically intended to be used together with this IVD to enable it to be used in accordance with its intended purpose. E.g. software intended for the analysis and interpretation of ELISA reader optical density results, line patterns or spot patterns of a blot. NB! If the software does the interpretation in addition to rendering it is an IVD MEDDEV on standalone software: modules Stand alone software may break down into a number of applications for the user where each of these applications is correlated with a module that may have a medical purpose or not Need to CE mark whole software product? Modules with intended purpose in scope of MDD / IVDD can be CE marked separately from the whole obligation of the manufacturer to identify the boundaries and the interfaces of the different modules/applications based on intended use If modules are intended for use in combination with other modules of the whole software structure, other devices or equipment, the whole combination, including the connection system, must be safe and must not impair the specified performances of the modules which are subject to the MDD / IVDD 13

14 Thank you! READ MY BLOG: Erik Vollebregt Axon Lawyers Piet Heinkade HC Amsterdam T M E erik.vollebregt@axonlawyers.com 14