Industry Advisory Team workshop I: Dealing with vendors Bridget Moorman, Michael Strübin, Continua Health Alliance U4H Industry Advisory Team

Industry Advisory Team Members

• European eHealth industry associations – Continua Health Alliance

– COCIR

– GSMA

• Company members include: – Bosch

– Cisco

– Intel

– Orange

– Philips

Mission

to provide advice to the Consortium from companies and people with profound knowledge of the

technologies available and of the market trends

Objectives • bringing together a team of experts in several fields from

industry leaders in the eHealth sector;

• managing the communication and the knowledge transfer between the IAT and the Project Team;

• Analysing and advising pilot regions on standards for interoperability between platforms and devices;

• Analysing the regulatory environment to identify barriers to deployment of telemedicine and interoperable, multi-vendor device chains

• Providing education both inside and outside the Project on standards, interoperability and regulatory issues affecting deployment.

3. Deliverables and division of labour

U4H Vendor Showcase

Ljubljana, 18 June 2013 supported by:

Vendor showcase supported by:

U4H vendors showcase

• Requested by consortium/coordinator

• Open, neutral , transparent

• “Free”: supported by sponsorship from Care Innovations, T-Systems, and Health Insight Solutions

• Education about state of the art solutions

• Opportunities to meet vendors Tuesday, 18 June

– Coffee breaks

– Lunch breaks

– Reception after 18.00

Participants • Intel-GE Care

Innovations

• T-Systems

• Health Insight Solutions Acute Technology / Brunel University

• AIT Austrian Institute of Technology

• BodyTel

• Bosch Healthcare

• Medvivo

• Modz

• S3 Group

Three quick reference guides

Thank you Bridget Moorman Michael Strübin

Interoperability: Basics Bridget Moorman, Technical Manager, Industry Advisory Team United4Health The Continua Health Alliance

Overview

• Definition of Interoperability • Interoperability – Why? • Interoperability at Interfaces • Sample HL7 messages with and without data standards • Continua Architecture • Acronym definitions • IHE • Summary

U4H PTC, Slovenia, June 2013

Interoperability

• Interoperability - the ability of a system or a product to work with other systems or products without special effort on the part of the customer

Why? • Drive market development towards standards based interoperability

– Goal to drive down long-term costs;

• Lessen infrastructure replacement costs

• As changes occur at different production cycles; can take advantage of those cycles without huge interfacing costs

– Can allow heterogeneous environment to inter-communicate

• flexible interfaces

U4H PTC, Slovenia, June 2013

Interoperability

Examples of non-standard based interface issues

• Use of different vendor’s glucometer resulted in new analysis and filtering interface being written to take into account different measurement range (off by 10%)

• Use of newer model of glucometer resulted in new software interface required for mobile phone due to “undocumented” features in transmission protocol from glucometer

• Use of newer model mobile phone due to market changes resulted in redo of software interfacing to medical device

• Use of different vendor’s medical device in hospital without data standards based interface resulted in rewrite of integration software to EHR

U4H PTC, Slovenia, June 2013

Interoperability • By adhering to published interface standards

– Interfaces

• Personal or Peripheral Area Network (PAN)

• Local Area Network (LAN)

• Wide Area Network (WAN)

• Health Record Network (HRN)

– Physical, Data and Messaging, Network Protocol

• Physical: DB9, DB22, USB

• Data: IEEE 11073, SNOMED, LOINC

• Messaging: HL7 (V2.x, 3.0)

• Network Protocol: NFC, Bluetooth, ZigBee, GSM, WiFi (IEEE 802.11)

U4H PTC, Slovenia, June 2013

Sample HL7 message without embedded IEEE 11073 Data encoding

U4H PTC, Slovenia, June 2013

• MSH|^~\&|DATACAPTOR||||20100827082930||ORU^R01|ID012829229700445000|P|2.3|||NE|NE||8859/1<CR>

• PID|||||<CR>

• PV1||I|HOSPITAL MON CVS 4201<CR>

• OBR|||||||20100827082930|||HOSPTITAL MON CVS 4201<CR>

• OBX|1|ST|1929||Mr Number||||||F<CR>

• OBX|2|ST|1930||Patient Name||||||F<CR>

• OBX|3|NM|1||93||||||F<CR>

• OBX|4|NM|14||100||||||F<CR>

• OBX|5|NM|646||1||||||F<CR>

• OBX|6|NM|2259||89||||||F<CR>

• OBX|7|NM|2260||43||||||F<CR>

• OBX|8|NM|2261||66||||||F<CR>

• ………

• What is the OBX? Determined by vendor HL7 specification guide

Sample HL7 message with embedded IEEE 11073 and SNOMED Data encoding

U4H PTC, Slovenia, June 2013

MSH|^~\&|AcmeInc^ACDE48234567ABCD^EUI-64||||20090713090030+0000||ORU^R01^ORU_R01|MSGID1234|P|2.6|||NE|AL|||||IHE PCD ORU-R01 2006^HL7^2.16.840.1.113883.9.n.m^HL7 PID|||789567^^^Imaginary Hospital^PI ||Doe^John^Joseph^^^^L^A|||M OBR|1|AB12345^AcmeAHDInc^ACDE48234567ABCD^EUI-64|CD12345^AcmeAHDInc^ACDE48234567ABCD^EUI 64|182777000^monitoring of patient^SNOMED-CT|||20090813095715+0000 OBX|1|CWE|68220^MDC_TIME_SYNC_PROTOCOL^MDC|0.0.0.1|532224^MDC_TIME_SYNC_NONE^MDC|||||R OBX|2||528391^MDC_DEV_SPEC_PROFILE_BP^MDC|1|||||||X|||||||0123456789ABCDEF^EUI-64 OBX|3||150020^MDC_PRESS_BLD_NONINV^MDC|1.0.1|||||||X|||20090813095715+0000 OBX|4|NM|150021^MDC_PRESS_BLD_NONINV_SYS^MDC|1.0.1.1|120|266016^MDC_DIM_MMHG^MDC|||||R OBX|5|NM|150022^MDC_PRESS_BLD_NONINV_DIA^MDC|1.0.1.2|80|266016^MDC_DIM_MMHG^MDC|||||R OBX|6|NM|150023^MDC_PRESS_BLD_NONINV_MEAN^MDC|1.0.1.3|100|266016^MDC_DIM_MMHG^MDC|||||R OBX|7|DTM|67975^MDC_ATTR_TIME_ABS^MDC|1.0.0.1|20091028123702||||||R|||20091028173702+0000

Interoperability - Procurement

• “The following interoperability standards are recommended and preferred …..”

• List by functional interface and OSI layer interface:

– Example: “Personal Area/Local Area Network; Physical, Data, Network, Transport layers”

• Certification and/or assurance of interoperability in heterogeneous environment (Continua Certification, IHE Conformance Statement)

• If market is sparse, still need to include interoperability language to send a message to market

– Can become a discriminator in final field of products

– Sets tone-communicates your organization’s vision for desire of interoperability

• Can be used in marketing materials to your customers – “We are interoperable based on standards”

U4H PTC, Slovenia, June 2013

NFC

Health Reporting

Network (HRN) Interface

Personal Device (PAN/LAN/TAN)

Weight Scale

Pulse Oximeter

Independent

Living Activity

Cardio / Strength

Adherence

Monitor

Glucose Meter

Pulse /

Blood Pressure

Thermometer

Peak Flow

Device Connectivity

Wide Area

Network (WAN)

Interface

EHR

PHR HIE

NHI

N

CCD

PCD 01

24

Water Gas

Temperature Fall

Continua E2E Architecture

Low Energy

HRN Device

WAN Device

Application Hosting Device

Acronyms

• NFC – Near Field Communication - a set of standards for smartphones and similar devices to establish radio communication with each other by touching them together or bringing them into close proximity, usually no more than a few centimeters (10 cm or less)

• PCD01 – IHE Patient Care Devices Domain Profile detailing medical device communication with another system – is agnostic towards network transmission protocols

• CCD – Continuity of Care Document –a constrained version of the HL7 Clinical document architecture (CDA) which is XML-based markup standard intended to specify the encoding, structure, and semantics of a patient summary clinical document for exchange

U4H PTC, Slovenia, June 2013

IHE-Overview

U4H PTC, Slovenia, June 2013

- Profiles define actors and transactions between the actors - Transactions specify standards between actors (identified at interfaces) - Medical Devices - IHE-Patient Care Devices Domain - Discharge summaries - IHE-Patient Care Coordination Domain - http://www.ihe.net/profiles/

Summary

• Interoperability

– the ability of a system or a product to work with other systems or products without special effort on the part of the customer

• Use of “standards based approach” helps to decouple acquisition decisions and drive down interfacing costs

• Need to include interoperability language in procurement documents to send a message to market

– List standards desired in products by functional and network layer interfaces

– Require certification (Continua) and/or demonstration of conformance (IHE-PCD)

U4H PTC, Slovenia, June 2013

Market situation

10/29/2013

Misaligned incentives

Lack of demand for interoperable

devices

Fewer interoperable

devices available

Buyers do not (cannot) require

standards compliance

10/29/2013

Example: USB

10/29/2013

ADC Monitor port

Serial port

Parallel (SCSI) port

Musical instrument digital interface port

Serial and Geoport

USB adoption

• USB Alliance: Compaq, DEC, IBM, Intel, Microsoft, NEC, Nortel

• Founded in 1994

• Prototype in 1995, standards in 1996, USB 2.0 in 2000

• Slow uptake:

– Incentive to produce to old ports

– Lack of demand for USB compatibility

10/29/2013

Then came… • Apple iMac G3

• Introduced in 1998

• No 3½ inch diskette drive

• Only USB ports

10/29/2013

Effect:

• Apple’s strong position in educational and graphic designer market

• Rising demand for USB peripherals

• Incentive for vendors to offer USB peripherals

• Death to the serial and parallel ports

An ecosystem was born

10/29/2013

Lessons?

• Educating buyers

• Strengthen demand side

• Strengthen ecosystem

10/29/2013

Opportunities

• Growing recognition of Continua guidelines (ITU, ISO)

• European Interoperability Framework / Antilope

• “Market push” from public buyers – Danish MoH mandates

Continua guidelines

– Aby Dhabi, Singapore, etc.

10/29/2013

Thank you! Bridget Moorman, CCE, bridget.moorman@continuaalliance.org Michael Strübin , michael.strubin@continuaalliance.org

Regulatory Compliance

Nicole Denjoy, COCIR Secretary General

Industry Advisory Team Workshop

2nd Project Assembly Monday 18 June 2013, Ljubljana (Slovenia)

Overview

1. What is COCIR? 2. European Regulatory Framework: Brief History and updates on MDDs 3. Trends 4. How the Medical Devices Directives apply to Telehealth? 5. What happens when several products (medical / non medical) form

an interconnected system? 6. When should a telehealth solution or a component be CE-marked? 7. What does it mean for healthcare providers? 8. Roles and responsibilities 9. Data Protection Regulation

What is COCIR?

COCIR represents the Industry Voice in Medical Imaging, Electromedical and Healthcare IT

Our Industry leads in innovative healthcare technologies and provides solutions for the complete care cycle Visit our website: www.cocir.org

COCIR Member Companies

COCIR National Trade Associations Members

Belgium Italy UK Spain

Netherlands Netherlands Finland France

Germany Germany Sweden Turkey

COCIR at International level: DITTA

European Regulatory Framework History • Medical Devices are regulated through 3 Directives:

– One on active implantable medical devices (AIMDD) – One on in-vitro diagnostic (IVD) – One on all other medical devices (MDD)

• Those are ‘New Approach’ Directives in which standards are playing an important complementary role (presumption of conformity to ERs)

• Standards are bringing the ‘state-of-art knowledge for some key products (principle of harmonized standards published in the JOCE)

• Those directives were written in the 1980’s, enforced in 1998 and constantly substantiated with additional elements and guidances

• 2008: Public consultation on the ‘recast’ • 2012: Draft European MD Regulation adpoted by EC • 2013-2014: Input from EP and European Council

Trends • Since last year, scandals in the press influencing policymakers to

strengthen the Regulatory Regime for MDs • Technology/clinical:

– Technology continues to evolve towards seamless integrated care with innovative solutions

– Minimal invasive procedures (i.e. more gentle methods for the elderly) more images for guiding Therapies than Diagnostic procedures

– Increasing number of IVD tests Imaging tells the ‘where’ – Request for Screening: One-third of all cancers could be cured if detected and

treated early earlier detection followed by less costly treatment / therapy – Personalized Medicine Biomarker research & imaging to characterize disease

fundamentals

• Regulatory: – Towards More regulations – Globalisation

Medical Device Regulation Update • Draft MD Regulation under active discussion at

European Parliament and Council levels

• ‘Joint Immediate Action Plan’ designed by EC and currently focusing on:

– Functioning of Notified Bodies

– Market Surveillance and Vigilance

– Unique Device Identification

Other developments at EC level

• EC (DG CONNECT) currently prepares a ‘Green Paper’ which will be published in the form of a public consultation in Sept. 2013

• Scope will cover Apps and Tablets

• 3 key questions:

– Should we regulate more under MDR?

– Should we regulate through another type of regulation?

– Should we do nothing?

Developments at International level

• Mar. 2012: DITTA submitted a NWIP proposal to suggest to regulators to come with some harmonisation for medical software

• Mar. 2013: IMDRF Management Committee approved this Work Item

• May 2013: Work Item started at IMDRF level under the US FDA lead

How the Medical Devices Directives apply to Telehealth?

What is a medical device? Article 1 of Directive 93/42/EEC

as amended by Directive 2007/47 implemented in march 2010

‘medical device’ means any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of:

— diagnosis, prevention, monitoring, treatment or alleviation of disease,

— diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,

— investigation, replacement or modification of the anatomy or of a physiological process,

— control of conception, and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means;

New definition of IVD Article 2(2) of the Regulation Proposal on IVD

of 26 September 2013

"‘in vitro diagnostic medical device’ means any medical device which is a reagent, reagent product, calibrator, control material, kit, instrument, apparatus, equipment, software 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;

– concerning a congenital abnormality;

– concerning the predisposition to a medical condition or a disease;

– to determine the safety and compatibility with potential recipients;

– to predict treatment response or reactions;

– to define or monitor therapeutic measures.

Specimen receptacles …"

When does telehealth solution or component qualify as a MD?

Telehealth solution as a whole:

Does not meet the definition of a MD.

Components of telehealth solutions are MD when:

Meet the definition of a MD (e.g. blood pressure monitor or software if performing an action on data different from

storage, archival, lossless compression, communication or simple search but treating data such as creating or modifying information).

EC guidelines on standalone software MEDDEV 2.1/6 of January 2012

Definition of standalone software

"'Standalone software' means software which is not incorporated in a medical device at the time of its placing on the market or its making available."

Introduction: recital 6 of Directive 2007/47/EC

• "… software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical

device, is a medical device.

• "Stand alone software for general purposes when used in a healthcare setting is not a medical device."

Standalone software as an accessory of a MD/IVD

Stand alone software that does not meet the definition of MD/IVD but is intended by the manufacturer to enable a MD/IVD to be used in accordance with its intended purpose, is an accessory to the MD/IVD.

An accessory to a MD/IVD falls respectively under the scope of Directive 93/42/EEC or

Directive 98/79/EC.

Stand alone software as active MD

• Article 1(2)(b) of Directive 93/42/EEC

Definition of active medical device

• "Any medical device operation of which depends on a source of electrical

• energy or any source of power other than that directly generated by the

• human body or gravity and which acts by converting this energy. Medical

• devices intended to transmit energy, substances or other elements between

• an active medical device and the patient, without any significant change,

• are not considered to be active medical devices.

• Stand alone software is considered to be an active medical device."

Summary from MDD 93/42/EEC substantiated by Directive 2007/47/EEC for stand-alone software

10/29/2013

1. Article 1: Change of Definition of Medical device - ‘medical device’ means any instrument, apparatus, appliance, software, material or other article…

2. New sub-clause ER 12.1a: “For devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification.”

3. Annex IX – Active Medical Device definition in the classification criteria added – “Stand alone software is considered to be an active medical device.”

Systems, modules and accessories

Mats Ohlson MPA 57

Combinations –

When several products (medical / non medical) form an interconnected system…

• They may create new functionality

– intended or not intended

• New risks may occur

– that can be hard to predict

Mats Ohlson MPA 58

System architecture

• Modular approach

– Separation medical modules / Non medical modules

– Define module limits and dependencies

– Problem to describe overall clinical performance and risks in combined system

• System approach

– Medical modules / Non medical modules CE-marked together

When should a telehealth solution or a component be CE-marked ?

10/29/2013

Software is a medical device if…

10/29/2013

(A) Software is a computer program

(B) Software is not incorporated in a medical device

(C) Software “action” is more than “basic data processing”

(D) Software has benefit for individuals

Software

falls under

MDD

regulations

(E) Intended purpose is acc. to MDD or software is an accessory acc. to MDD’s definition

Example: Software as accessory according to the MDD

10/29/2013

© R

ain

er S

turm

/ w

ww

.pix

elio

.de

Monitoring/controling infusion pump

Classification of stand alone software: intended use is driving...

10/29/2013

Rule # Summary Classification

9 All active therapeutic devices intended to administer or exchange energy

Class IIa unless potentially hazardous way then Class IIb

10 Active devices intended for diagnosis Class IIa or Class IIb (e.g. ionizing radiation)

11 Active devices to administer or remove medicines, body liquids, or other substances

Class IIa unless potentially hazardous way then Class IIb

12 All other Active Devices (“fall through” rule)

Class I

• Annex IX, 2.3: SW which drives a device or influences the use of a device, falls automatically in the same device class.

European Harmonized Standards

10/29/2013

Standard Topic

EN 62304:2006 Medical device SW – SW lifecycle processes

EN ISO 13485 Medical devices - Quality management systems –

Requirements for regulatory purposes

EN ISO 14971 Medical devices – Application of risk management to

medical devices (Note: Normative reference in EN 62304)

EN 60601-1 Medical electrical equipment – General requirements for

basic safety and essential performance – Section 14:

Programmable electrical medical systems (PEMS) (Note:

Not harmonized to IVD Directive)

EN 62366 Medical

Devices

Application of usability engineering to medical devices

Under development:

• IEC 82304-1 Ed. 1.0 Healthcare Software Systems - Part 1: General requirements

• IEC 62304 Ed. 2.0

International Guidance

10/29/2013

Guidance Topic

MEDDEV 2.1/6 (2012) Guidelines for the qualification and

classification of standalone SW used

within healthcare within the regulatory

framework of medical devices

IEC/TR 80002-1:2009 Medical device SW - Part 1: Guidance

on the application of ISO 14971 to

medical device SW

NB-MED/2.2/Rec4 SW and Medical Devices (2001)

Manual on Borderline and

Classification in the Community

Regulatory Framework for

Medical Devices

Picture Archiving and Communication

Systems (PACS) is included

What does it mean for healthcare providers? Roles and responsibilities of key players

CE-marking is not only to affix a CE-label!

Manufacturer is responsible for:

Defining:

– intended use

– specifications and boundaries of the device

Ensuring:

– that adequate functionality and performance support the claim of the intended (medical) purpose

– that patient safety is considered in the risk management process

Presenting:

– an evaluation showing that the performance of the product actually meets the medical purpose

Mats Ohlson MPA 66

Healthcare providers

• Need to make sure the system chosen has elements in compliance with regulations where appropriate

Data Protection Regulation

Where are we?

• 25 Jan. 2012: Draft EU regulation adopted by EC and given to EP and Council

• Jan. 2013: EP rapporteur issued draft report

• Q3 2013: EP 1st reading

• H1 2014 (?): EU regulation adoption

• Healthcare Stakeholder involvment:

– Jan. 2013: Healthcare Coalition on Data Protection

Healthcare Coalition On data Protection

CED: The Council of European Dentists (CED) is the representative organisation of the dental profession in the European Union FEAM: The Federation of European Academies of Medicine (FEAM) represents national academies in 14 EU member states CPME: The Standing Committee of European Doctors (CPME) represents national medical associations across Europe. COCIR: COCIR represents the Radiological, Electromedical and Healthcare IT industry in Europe. EFPIA: The European Federation of Pharmaceutical Industries and Associations (EFPIA) represents the pharmaceutical industry operating in Europe Continua Health Alliance: Continua Health Alliance is a non-profit, open industry organization of healthcare and technology companies joining together in collaboration to improve the quality of personal healthcare GSMA: The GSMA represents the interests of mobile operators worldwide HOPE: HOPE, the European Hospital and Healthcare Federation, represents national public and private hospital associations and hospital owners