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, [email protected] Michael Strübin , [email protected]
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