UKRAINE: Public Disclosure Authorized RURAL HEALTH AND TELEMEDICINE
TELEMEDICINE IMPLEMENTATION HANDBOOK Public Disclosure Authorized Public Disclosure Authorized Public Disclosure Authorized Ukraine: Rural Health and Telemedicine
Telemedicine Implementation Handbook
HNP Report No: AUS0001597
Prepared by: Dr. John Chelsom Dr. Conceição Granja Bartnæs Prof. Abdul Roudsari
May 25, 2020 Ukraine: Rural Health and Telemedicine
© 2020 The World Bank 1818 H Street NW, Washington DC 20433 Telephone: 202-473-1000; Internet: www.worldbank.org Some rights reserved This work is a product of the staff of The World Bank. The findings, interpretations, and conclusions expressed in this work do not necessarily reflect the views of the Executive Directors of The World Bank or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of The World Bank concerning the legal status of any territory or the endorsement or acceptance of such boundaries. Rights and Permissions The material in this work is subject to copyright. Because The World Bank encourages dissemination of its knowledge, this work may be reproduced, in whole or in part, for noncommercial purposes as long as full attribution to this work is given. Attribution – Please cite the work as follows: “World Bank. 2020. Ukraine: Rural Health and Telemedicine. Telemedicine Implementation Handbook. © World Bank.” All queries on rights and licenses, including subsidiary rights, should be addressed to World Bank Publications, The World Bank Group, 1818 H Street NW, Washington, DC 20433, USA; fax: 202-522-2625; e-mail: [email protected].
2 Ukraine: Rural Health and Telemedicine Foreword
FOREWORD
Ukraine is a developing country in the east of Europe. The country launched important health reforms beginning in 2017 with the establishment of a strategic purchasing function and change of payment for primary health care. The financing reform initiated new opportunities for patients and primary care providers: for patients, the reform institutionalized the opportunity to select (and change) a primary care physician; for providers, the reform created incentives for improved customer experiences and quality of care. Within just 18 months from the start of primary care transformation, about 30 million patients, or over 70 percent of Ukrainians, enrolled with primary care physicians by signing a declaration of choice of primary care doctor. In 2019, electronic prescriptions were introduced for reimbursable outpatient drugs. The Health Index survey measured patient satisfaction in 2019 and reported 73 percent population satisfaction with the quality of care at the primary level, compared to only 52 percent satisfied with hospital care. In 2018, the Government of Ukraine decided to support strengthening of primary care by investing in modernization of its infrastructure to provide better access to services and by supporting the development of telemedicine. The World Bank partnered with the Government of Ukraine and provided guidance on technical and operational requirements for the Telemedicine system in Ukraine, using resources from the World Bank’s analytical and advisory services and with support from the “Support Reforms and Good Governance in the Health System in Ukraine” project financed by the Swiss Development Cooperation Office in Ukraine. With consideration of global best practices for the development of eHealth systems as well as the current telehealth initiatives in Ukraine supported by the Canadian Government, the World Bank team conducted regional and national assessments and developed recommendations for the design of the Telemedicine system. A summary of the recommendations, including aspects of the required hardware, software and connectivity, and the mode of operating system are presented in this Handbook. I believe the relevance and interest in the development of telemedicine, and the possibilities it offers will continue to be of critical and growing importance in the coming years. Especially in the midst of the current COVID-19 pandemic, telemedicine has become an essential function as the organization of health
3 Ukraine: Rural Health and Telemedicine systems around the world have changed and adapted in order to meet even the most basic health needs of citizens. I hope the guidance provided in this Handbook will benefit many countries in their development and strengthening of telemedicine capabilities. I would like to express appreciation for the support provided in achieving this Handbook to its authors, who were guided by the development of telemedicine in the UK, Canada, Norway, Portugal and other countries. I am also grateful to the Head of the expert group on health reform implementation at the Ministry of Health of Ukraine, Ms. Tetiana Orabina, and the Sector Lead at the Ministry of Regional Development of Ukraine, Ms. Olena Voskoboynyk, for their leadership and coordination in the initial steps of telemedicine development in Ukraine. The World Bank team engaged in the preparation of the Handbook was chaired by Ms. Olena Doroshenko, Health Economist, and comprised of the national expert on telemedicine, Mr. Vyacheslav Polyasnyy, international consultant Ms. Laura Poole, and national consultant Ms. Khrystyna Pak. Excellent logistical support to the team was provided by Ms. Kseniya Bieliaieva. The World Bank team is grateful for the support provided by Rivne and Odesa regional eHealth and telemedicine teams, specifically by Mr. Mykola Syrochuk, from the Rivne team, who provided thoughtful feedback and helped with practical implementation of the recommendations. Finally, I would like to thank my colleagues, Ms. Marelize Gorgens, Senior Monitoring and Evaluation Specialist, Mr. Zlatan Sabic, Senior Operations Officer, and Mr. Dominic Haazen, Lead Health Policy Specialist, who provided peer review of this Handbook and helped improve it prior to this publication.
Feng Zhao, Practice Manager (Program Leader for Human Development in Belarus, Moldova and Ukraine at the time of preparing this publication)
4 Ukraine: Rural Health and Telemedicine Summary
SUMMARY This Handbook provides practical guidance and recommendations of best practice for the implementation of Rural Telemedicine. It covers the Technical Architecture, Functional Profiles, Standards, Infrastructure, Products (hardware and software), Implementation Procedures, Organisation, operational procedures and methods for Evaluation of Rural Telemedicine Services, with guidance for requirements at national, regional, district and local level. This report has been tailored to the specific priorities, needs and capabilities of Ukraine and the points at which information specific to Ukraine should be considered during implementation of Telemedicine Services is shown in boxes such as this one. The main recommendations made in the Handbook for the implementation of Rural Telemedicine are: 1. Establishment of national and regional Telemedicine Service Organisations, responsible for the implementation of Rural Telemedicine Services. 2. Regional implementation, with each specific implementation developing a Vision Document and Terms of Reference, based on the guidance in this handbook, with inclusion of relevant national and local regulations and best practice. 3. Implementation using Agile methodologies and recognised best practice for project management. 4. Integration with national-level eHealth services, where these are available. 5. Adoption of internationally recognised Open Standards at every point of the Telemedicine Service implementation. 6. High bandwidth fibre data connections to Regional and District Hospitals. 7. At least 3G wireless connection to local Ambulatory Centres (including Feldsher-Midwife Stations). 8. Data Centres located at Regional (and some District) Hospitals, running a virtual machine architecture (Hypervisors) and Virtual Desktop Infrastructure. 9. Clinical Workstations running Virtual Desktops, through the regional or district Virtual Desktop Infrastructure
5 Ukraine: Rural Health and Telemedicine
10. Telemedicine Applications integrated with the Medical Information System, used on the Virtual Desktop. 11. Medical Devices integrated with Telemedicine Applications, using open standards 12. National-level accreditation of Products, verified in a formal Sandbox environment. 13. Regional procurement from a Product Catalogue of hardware, devices and software products which have achieved national-level accreditation. 14. Formal evaluation of deployed Telemedicine Services, to feedback learning and validate the use of best practice.
In Ukraine, there is an opportunity to implement Telemedicine Services in conjunction with the developing national eHealth infrastructure. The following specific recommendations are made: 1. Where possible, the Technical Architecture for Telemedicine Services should utilise National eHealth services, particularly for Patient Identifiers and Demographics. If these are not yet implementable in a Region, then provision should be made to integrate with the national services as and when they come online. 2. This handbook recommends that Telemedicine Applications are integrated with the MIS. This is because Telemedicine and electronic record keeping (in the MIS) go hand-in-hand. To implement Telemedicine Services without MIS risks the creation of large volumes of unaccountable patient information and/or clinical decisions with are based on unrecorded and unverifiable information. 3. The current state of the market for MIS in Ukraine presents a window of opportunity to implement MIS which operate across primary and secondary care, and which are properly integrated with Telemedicine Services. If this opportunity is not seized, it will lead to the same issues of fragmented patient information and systems which create a long-term problem for data integration. 4. The Infrastructure recommended here for Telemedicine can be shared with emerging eHealth systems as they are implemented in each Region; in particular, the infrastructure can be shared with the implementation of MIS and PACS
6 Ukraine: Rural Health and Telemedicine Summary
5. It will be important to establish a National level Product Catalogue, with products verified through testing in a National-level Sandbox. This will ensure that sound purchasing decisions are made at Regional and District level and should help to reduce the overall cost of procurement for Products. 6. Open standards for the exchange of healthcare information are as important for Telemedicine Services as they are for eHealth in general. Where possible, the standards used for Telemedicine should be the same as those agreed nationally for eHealth. Where the timing of implementation for Regional Telemedicine Services does not allow this, then open standards should be used, with a view to transformation and/or migration to agreed standards at a future date. 7. It is important to identify exemplar sites in Ukraine that can be used to verify the approach to Telemedicine Services recommended in this Handbook, that can be formally evaluated to feedback ‘lessons learned’ and can be used as Case Studies to guide future developments in Ukraine.
Professor Abdul Roudsari
7 Ukraine: Rural Health and Telemedicine
TABLE OF CONTENTS
1 How to Use This Handbook 14
2 Technical Architecture 16 2.1 Point of Care 2.2 Telemedicine Service 2.3 Remote Care Provider 2.4 Integration 2.4.1 Data Integration 2.4.2 Functional Integration 2.4.3 Integration of Regional and National Level Systems 2.4.4 Public and Private Cloud Integration 2.5 Telemedicine Workstation 3 Functional Profiles 30 3.1 Stakeholders 3.2 Functional Profile – Teleconsultation 3.2.1 Scenarios 3.2.2 Locations 3.2.3 Products 3.2.4 Work Breakdown Structure 3.2.5 Service Delivery Protocol 3.2.5.1 Scenario Point of Care Clinician (without patient) – Expert Clinician 3.2.5.2 Scenario Point of Care Clinician (with patient) – Expert Clinician 3.2.5.3 Scenario Patient – Expert Clinician 3.2.6 Care Pathways 3.3 Functional Profile – Telemonitoring of Chronic Conditions 3.3.1 Scenarios 3.3.2 Locations 3.3.3 Products 3.3.4 Work Breakdown Structure 3.3.5 Service Delivery Protocol 3.3.5.1 Scenario Synchronous
8 Ukraine: Rural Health and Telemedicine Table of Contents
3.3.5.2 Scenario Asynchronous 3.3.6 Care Pathways 3.4 Functional Profile – Telecardiology 3.4.1 Scenarios 3.4.2 Locations 3.4.3 Products 3.4.4 Work Breakdown Structure 3.4.5 Service Delivery Protocol 3.4.5.1 Scenario Synchronous outpatient 3.4.5.2 Scenario Synchronous emergency 3.4.6 Care Pathways 3.5 Functional Profile – Telediagnosis 3.5.1 Scenarios 3.5.2 Locations 3.5.3 Products 3.5.4 Work Breakdown Structure 3.5.5 Service Delivery Protocol 3.5.5.1 Scenario Diagnosis/Opinion Expert Clinician 3.5.5.2 Scenario Point of Care Clinician (with Patient) – Expert Clinician 3.5.6 Care Pathways 3.6 Functional Profile – Teleradiology 3.6.1 Scenarios 3.6.2 Locations 3.6.3 Products 3.6.4 Work Breakdown Structure 3.6.5 Service Delivery Protocol 3.6.5.1 Scenario Point of Care Clinician (with the patient) – Expert Clinician 3.6.5.2 Scenario Reporting by Expert Clinician (Elective and Emergency) 3.6.6 Care Pathways 3.7 Functional Profile – Telescreening Services 3.7.1 Scenarios 3.7.2 Locations 3.7.3 Products
9 Ukraine: Rural Health and Telemedicine
3.7.4 Work Breakdown Structure 3.7.5 Service Delivery Protocol 3.7.5.1 Scenario Telescreening generating DICOM based data 3.7.5.2 Scenario Telescreening generating non-DICOM based data 3.7.6 Care Pathways 3.8 Functional Profile – Tele-education 3.8.1 Scenarios 3.8.2 Locations 3.8.3 Products 3.8.4 Work Breakdown Structure 3.8.5 Service Delivery Protocol 3.8.6 Care Pathways 4 Standards 67 4.1 Personal Health Devices Interface 4.1.1 NFC Interface 4.1.2 USB Interface 4.1.3 Zigbee Interface 4.1.4 Bluetooth Interface 4.1.5 Bluetooth Low Energy Interface 4.1.6 Security And Privacy 4.2 Services Interfaces 4.2.1 Data Payloads 4.2.2 Message Exchange Frameworks 4.2.3 Security and Privacy 4.3 Healthcare Information System Interface 4.3.1 Data Payload 4.3.2 Message Exchange Framework 4.3.3 Security & Privacy 5 Infrastructure Specifications 76 5.1 Private Healthcare Network 5.2 Network Connections and Bandwidth 5.3 Healthcare Professional Email Service 5.4 Communications Between Regional and District Hospitals
10 Ukraine: Rural Health and Telemedicine Table of Contents
5.5 Networking at Regional and District Hospitals 5.6 Data Centres at Regional and District Hospitals 5.6.1 Site Selection and Preparation 5.6.2 Electrical Systems 5.6.3 Network Infrastructure 5.6.4 Heat Rejection and Cooling System 5.6.5 Fire Suppression and Detection 5.6.6 Data Centre Monitoring 5.6.7 Data Centre Support Requirements 5.7 Virtual Data Centre 5.7.1 Hypervisor 5.7.2 Information Technology Equipment 5.8 Teleconsultation Room 5.9 Communications to/from Ambulatory Centres 6 Product Catalogue – Hardware 105 6.1 Category – Server Hardware for Virtual Data Centre 6.2 Category – Security Appliance for Virtual Data Centre 6.3 Category – WAN / PE Router for Virtual Data Centre 6.4 Category – Network Switches for Virtual Data Centre 6.5 Category – Storage Array for Virtual Data Centre 6.6 Category – Data Protection Appliance for Virtual Data Centre 6.7 Category – Data Replication Appliance for Virtual Data Centre 6.8 Category – 3G / 4G LTE Antenna (for Rural Ambulatory Centre) 6.9 Category – Router (for Rural Ambulatory Centre) 6.10 Category – Desktop Computer (Telemedicine Workstation) 6.11 Category – Thin Client Computer (Telemedicine Workstation) 6.12 Category - USB to Bluetooth Adapter 6.13 Category - USB to Zigbee Adapter 6.14 Category – Video Conferencing Kit 6.15 Category – Multi-Lead ECG 6.16 Category – Digital Stethoscope 6.17 Category – Pulse Oximeter 6.18 Category – Digital Dermatoscope 6.19 Category – Digital Sphygmomanometer
11 Ukraine: Rural Health and Telemedicine
6.20 Category – Digital Scale 6.21 Category – Digital Spirometer 6.22 Category – Digital Glucometer (Invasive) 6.23 Category – Digital Ophthalmoscope (Fundus Imaging) 6.24 Category – Digital Image Capture System (Telepathology) 6.25 Category – Generic Wearable Devices 6.26 Category – Generic Sensors 6.27 Category – Generic Body Fluids Analysis 7 Product Catalogue – Software 129 7.1 Category – Hypervisor 7.2 Category – Virtual Desktop Infrastructure 7.3 Category – Remote desktop USB redirection 7.4 Category – Directory Services 7.5 Category – Email Server 7.6 Category – Enterprise Master Patient Index (EMPI) 7.8 Category – Integration Engine 7.9 Category – Support Ticket System 7.10 Category – Medical Information System (MIS) 7.11 Category – Picture Archiving and Communications System (PACS) 7.12 Category – Teleconsultation Application 8 Implementation Procedures 140 8.1 Vision Document 8.2 Work Breakdown Structure (WBS) 8.3 Project Estimation 8.4 Project Costing 8.5 Timescales (Project Plan) 8.6 Risk Register 8.7 Terms of Reference 8.8 Project Governance – ISO 21500 8.9 Unified Process (of Software Engineering) 8.10 Scrum Methodology 9 Organisation and Operational Procedures 152 9.1 Barriers to Adoption
12 Ukraine: Rural Health and Telemedicine Table of Contents
9.2 Organisational Structure 9.2.1 National Telemedicine Service Organisation 9.2.2 Regional Telemedicine Service Organisation 9.2.3 District Telemedicine Service Team 9.2.4 Local Telemedicine Users 9.3 Support and Maintenance 9.3.1 Actors 9.3.2 Levels of Support 9.3.3 Products 9.3.4 Support Service Protocols 9.3.4.1 Scenario FAQ 9.3.4.2 Scenario Online forms 9.3.4.3 Scenario Email 9.3.4.4 Scenario Telephone 9.3.4.5 Scenario Chat (Using the Teleconsultation Service) 9.4 Training and Education 9.4.1 Clinician Training 9.4.1.1 On-Site 9.4.1.2 Video Conference 9.4.2 Technical Training 9.4.3 Custom Training Programs 10 Evaluation Procedures 166 10.1 Information System (IS) Success Model 10.2 Canada Health Infoway Benefits Evaluation Framework 10.3 Proposed Evaluation Framework 11 Case Studies 171 12 Bibliography 172 13 Glossary 173
13 Rural Telemedicine in Ukraine – Implementation handbook
1 HOW TO USE THIS HANDBOOK
This Implementation Handbook for Rural Telemedicine contains specifications and recommendations for best practice in the commissioning, implementation and operation of Telemedicine Services. It contains some specification of infrastructure and organisation at the national level, but is focussed on the delivery of services across a region. Telemedicine Services should be delivered through a Private Healthcare Network – a Virtual Private Network (VPN) connecting Virtual Data Centres located at regional and district hospitals with Workstations at the Point of Care, which may be in properly equipped Teleconsultation Rooms at the hospitals or at Ambulatory Centres (Primary Health Care Centres, Medical Outpatient Centres or Feldsher-Midwife Stations). The Private Healthcare Network between Virtual Data Centres should run over fibre network connections and the Ambulatory Centres should normally use a 3G or 4G mobile data connection through a suitable external antenna and router which delivers wired Ethernet and wireless local area network to the centre. The Telemedicine Encounter is made between a clinician and/or patient at the Point of Care and an Expert Clinician at a Remote Care Provider (normally a district or regional hospital). Every encounter must be centred around an identified patient, involve properly identified and authenticated clinician users and be scheduled/initiated through the Medical Information System (MIS) for the patient, in which the notes and any associated data from the encounter are recorded. The infrastructure of the Telemedicine Service enables this through a Directory Service of clinical users, an Enterprise Master Patient Index (EMPI), an Integration Engine, a Medical Information System and a Picture Archiving and Communications System (PACS), all of which are hosted in the Virtual Data Centres. In addition, these data centres host the Virtual Desktop Infrastructure which delivers a remote desktop, running the MIS client and a Local Data Hub, to Workstations at the Point of Care. The Local Data Hub is used to integrate patient data gathered from Medical Devices (sensors and analysers) that transfer data to the local, encrypted disk of the Workstation through Bluetooth, USB or Zigbee interfaces.
14 How to Use This Handbook
The Technical Architecture for Telemedicine Services is designed to deliver a secure, robust and reliable service, even to Ambulatory Centres with a low bandwidth connection (although a sufficient minimal level of connectivity must be ensured). It is also designed to be easy to deploy and maintain, through the Virtual Data Centres and Virtual Desktop Infrastructure, with the minimum number of applications for the clinical users (ideally all Telemedicine Service functionality is delivered through integration with the MIS). This Handbook defines a set of Functional Profiles for Telemedicine Services, the most important of which is the Teleconsultation Service that forms the basis of many of the other profiles. The Functional Profile specifies the Service Delivery Protocol (or workflow) for the service, the Infrastructure and Products required (hardware and software) for implementation, and the Work Breakdown Structure for implementation. Each category of product is described in the Product Catalogue, that specifies the required functional specification and open standards for the Product Category. To be included in the Product Catalogue, products should be installed and verified in the Telemedicine Sandbox – a reference technical environment that implements the Technical Architecture described in this Handbook. Telemedicine Services are commissioned and implemented using the defined Implementation Process which combines standard best practice from ISO 21500, the Unified Process and the agile Scrum methodology. By following this process, a Terms of Reference for the procurement of any Infrastructure or Telemedicine Service can be prepared from the Technical Architecture, Functional Profiles and Product Catalogue. Once procured, the Telemedicine Service is then implemented, deployed, operated, maintained and supported through the Organisational Structures and Procedures outlined in this Handbook.
15 Ukraine: Rural Health and Telemedicine
2 TECHNICAL ARCHITECTURE
Point Telemedicine Remote Care of Care Service Provider
Telemedicine Carer(s) Service Organisation Directory ЕМРІ Email Services Services Healthcare Patient Provider Organisation
Service Community Applications Care Control Control Medical Acoess Acoess (Mobile) Devices Monitoring Medical And Data Devices Collection MIS PACS Specialist Storage Storage Systems, Tools and Equipment
Data Іntegration Integration Integration Data Store Engine Engine Engine Store Local Integration Local Integration Hub Hub
Virtual Telemedicine Core Desktop Telemedicine Core Applications MIS Infrastructure Applications MIS MIS MIS Work station Work station
Network Network
16 Ukraine: Rural Health and Telemedicine Technical Architecture
This general Technical Architecture supports patient-to-clinician and clinician- to-clinician Telemedicine Encounters (sessions), for both synchronous and asynchronous (store-and-forward) Telemedicine. The objective is that Telemedicine Services can be implemented using a stand- alone infrastructure, with the possibility to connect and interoperate with national eHealth services where and when they are available. The Architecture also supports the essential pre-requisites for any Telemedicine Encounter, which are: • the patient must be identified • the professional carers (clinicians) must be identified • the encounter must be recorded in the patient record These pre-requisites are ensured by the components of the Telemedicine Service, shown at the centre of the Architecture diagram. This service manages every Telemedicine Encounter between the Point of Care (shown on the left) and the Remote Care Provider (shown on the right). The components of the Architecture may be physically distributed between local, district, regional and national levels:
National Hospital, Specialist Centre, National Service, Public Health
Regional Hospital, Specialist Centre, Emergency Centre, Regional Service
District Hospital, Polyclinic, Emergency Centre, District Service
Local Ambulatory Centre, Pacient Home, Mobile Unit, Ambulance
17 Ukraine: Rural Health and Telemedicine
A specific implementation of a Telemedicine Service, as defined by its Functional Profile,will have a specific distribution of the components (and some components may be omitted) so that the Architecture can be depicted as a grid.
Point Telemedicine Remote Care of Care Service Provider
National
Regional
District
Local
The Technical Architecture should follow the same overall model in every region, and the product components (both hardware and software) should only be selected/procured from the Product Catalogue, but the exact configuration and its implementation will be determined and managed in each region, with consideration for the specific needs, priorities and capabilities of the region. Some components may be split between more than one level, or be configured differently within the same region. For example, there are likely to be Integration Engines running at District, Regional and National levels.
18 Ukraine: Rural Health and Telemedicine Technical Architecture
2.1 Point of Care
The Point of Care is the physical location at which Point the care, advice or opinion from the Remote Care of Care Provider is received. If present, the patient is always located at the Point of Care, although for some Functional Profiles the patient may not be present Carer(s) (in the case of clinician-to-clinician consultation, for example). At the local level, the Point of Care is an Ambulatory Patient Centre, which could be a Primary Health Care Centre, a Medical Outpatient Centre or a Feldsher- Midwife Station. Once the patient is referred for specialist care, the Point of Care moves to a hospital or specialist facility at District or Regional Medical level. Devices Medical Devices are hardware devices for monitoring Monitoring And Data and collection of patient information at the Point of Collection Care. These are connected to a Local Integration Hub which has the task of transferring information to the Telemedicine Service for persistent storage, typically in the Medical Information System for the patient.
Data Іntegration The Workstation runs the Local Integration Hub, Engine Store which interfaces with Medical Devices, and the Local Integration Hub MIS, through which all Telemedicine Applications are delivered. Telemedicine Core Applications MIS MIS Work station
19 Ukraine: Rural Health and Telemedicine
2.2 Telemedicine Service
The Telemedicine Service hosts systems Telemedicine infrastructure and applications that enable Service Telemedicine Encounters between the Point of Care and Remote Care Providers. The Directory Services provides a single registry for all clinical users of the Telemedicine services. Directory ЕМРІ Email Services Services The Enterprise Master Patient Index (EMPI) manages the unique identity of each patient, acting as a broker if a patient has multiple identifiers in different systems. Email Services provide a secure, dedicated email Service Applications service for clinical users. Control Control Acoess Acoess The Integration Engine pulls together all information about patients by routing messages between systems and transforming information into standard formats for storage in the Medical MIS PACS Information System (MIS) and Picture Archiving Storage Storage and Communications System (PACS). The patient record, shared between all participants in the Telemedicine Encounter, is stored in the MIS and PACS. Integration Engine The Service Applications enable specific types of Telemedicine Encounters, using the Workstations that are served desktop hrough the Virtual Virtual Desktop Infrastructure. Desktop Infrastructure
20 Ukraine: Rural Health and Telemedicine Technical Architecture
2.3 Remote Care Provider
The Remote Care Provider is the physical location Remote Care at which clinical care, advice or opinion is made, Provider for delivery to the remote Point of Care. This may be a specialist centre that acts solely as a Telemedicine Telemedicine Service Provider; or a Healthcare Service Provider Organisation such as a hospital or clinic, Organisation where some time and resources have been allocated to providing Telemedicine Services; or Healthcare mobile Community Care, where a care worker Provider Organisation is enabled with the facilities needed to connect remotely to the Point of Care (for example, this could be a General Practitioner providing advice Community to a Feldscher at a village Ambulatory Centre) Care (Mobile) The Expert Clinicians at the Remote Care Provider will generally use the applications that are Medical provided through the Telemedicine Service, but Devices may also use more specialist systems, tools or equipment that is only accessible at the Remote Specialist Systems, Tools Care Provider. and Equipment Any patient information generated in the specialist systems as part of the Telemedicine Encounter must be transferred to the patient record in the Integration Data Telemedicine Service through the Local Integration Engine Store Local Integration Hub. Hub
Telemedicine Core Applications MIS MIS Work station
21 Ukraine: Rural Health and Telemedicine
2.4 Integration
Integration of the Telemedicine Service within the day-to-day provision of healthcare is a vital factor in ensuring adoption by clinicians. The overall objective of Telemedicine is to improve outcomes for patients and to enable clinicians to deliver those outcomes; without proper integration of the Telemedicine Service, neither of those objectives can be achieved. There are two aspects to the integration of any healthcare systems; data integration and functional integration. Data integration is concerned with the aggregation of clinical information from multiple sources, to provide an integrated record or view for every patient. Functional integration is concerned with the actions performed by users of healthcare systems, so that the sequence of those actions is orchestrated into a single workflow.
22 Ukraine: Rural Health and Telemedicine Technical Architecture
2.4.1 Data Integration
Data integration is concerned primarily with transferring data from Medical Devices to the patient record, stored as part of the MIS. This is achieved in a number of steps, starting from the device, at the Point of Care: 1. Connect the Medical Device to the local Workstation 2. Identify the patient whose data is stored/gathered on the device 3. Transfer the data to the Local Integration Hub 4. Transfer data from the Local Integration Hub to the Integration Engine, running as part of the central Telemedicine Service 5. In the Integration Engine, verify the patient identity, transform the data to a standard format, route the data to the correct MIS store. 6. Acknowledge transfer of the data with the Local Integration Hub 7. Remove the data from the cache on the Local Integration Hub
Regional / Integration Telemedicine MIS District Engine App Data Storage
Data Integration Telemedicine Core Srore Engine Application MIS Local Medical Local Integration Hub MIS Devices Workstation
Telemedicine applications that are integrated (functionally) with the MIS may use their own Data Store. In this case, any such data that form part of the patient record (i.e. data that provide a record of the encounter between the patient and clinician and/or data that may be required to inform future healthcare decisions about the patient) should be transferred to the MIS Storage through the Integration Engine.
23 Ukraine: Rural Health and Telemedicine
2.4.2 Functional Integration
Functional integration is concerned primarily with the embedding of the workflow and actions of the Telemedicine Encounter within the MIS. The main objectives in doing this are to: • ensure that all patient data used and gathered in the Telemedicine Encounter is stored and accessed through the MIS • reduce the number of software applications that clinicians need to use (ideally, they should just use the MIS) • enforce for the Telemedicine Encounter, the same user authentication, patient identification and access control as are used by the MIS The integration is achieved through the Application Programming Interfaces (APIs) of the MIS and the Telemedicine Applications. The integration may be tightly coupled (preferred) or loosely coupled, depending on the capabilities of the APIs.
A Regional / Tele e icine A A licati n District Functional Integration
ata nte rati n Tele e icine re r re n ine A licati n Local e ical Local Integration Hub MIS e ice Workstation
Since the MIS is a key component of the Telemedicine Service, only those MIS products that have the capability for tightly coupled integration should be considered for procurement. Similarly, the Teleconsultation application is use in most of the Functional Profiles for Telemedicine, so this application too should have the capability for tight integration. In a tight integration, individual functions of the Telemedicine Application are available through its API, so that steps of the workflow that use the application can be embedded within the functionality of the MIS. In a more loosely coupled integration, a sequence of steps in the workflow may be achieved by launching the Telemedicine Application from within the MIS, but with the application then running in its own process/interface.
24 Ukraine: Rural Health and Telemedicine Technical Architecture
2.4.3 Integration of Regional and National Level Systems
Data and functional integration can be made between the regional level Telemedicine Services and the national eHealth services, when they are available. The main integration at this level is with national services for: • Directory services - user credentials and access permissions • EMPI - patient identifier(s) and demographics • MIS - the summary record for a patient Data integration can be made directly between the Integration Engines running at Regional and National level, exchanging messages using HL7 v2, CDA or FHIR. Both functional and data integration can be achieved using the published web services APIs of the national eHealth services: https://edenlab.atlassian.net/wiki/spaces/EH/overview - overall API overview https://ehealthmedicaleventsapi.docs.apiary.io/# - medical events / MIS API overview
National Directory Services ЕМРІ MIS
Integration Engine Web Services (АРІ)
Integration Engine Web Services (АРІ)
Directory ЕМРІ MIS Regional Services
25 Ukraine: Rural Health and Telemedicine
2.4.4 Public and Private Cloud Integration
Some medical devices are shipped with integrated applications which store and analyse data from the device using a public cloud service. When such devices are used in the presence of a clinician at the Point of Care, then the cloud service should be run inside the Private Healthcare Network with the data and functionality of the application integrated with the MIS. Medical devices used for monitoring of chronic conditions (e.g. diabetes, hypertension) may be used by patients in their home or at general locations away from the Ambulatory Centres and without the presence of a clinician. In such situations, the data collected by the Medical Device may be stored and then transferred at a later date through the Telemedicine Workstation, in the presence of a clinician, during a Telemedicine Encounter.
Tele e icine A licati n Regional / nte rati n n ine t ra e A licati n District MIS
Tele e icine Tele e icine re Local A licati n A licati n e ical MIS e ice Workstation
Alternatively, the patient may choose to upload data to a public cloud service, run by the provider of the Medical Device. Any such data remain under the control of the patient but may be transferred to the patient's MIS through a Trusted Gateway to the Private Healthcare Network. This gateway, established between the private provider of the public cloud service and the National Telemedicine Service, allows for the secure transfer of identified patient data from the public cloud to the Integration Engine running Private Healthcare Network. The national level Integration Engine is then responsible for routing to the correct regional engine, which then transforms the data and stores in the patient record (MIS Storage).
26 Ukraine: Rural Health and Telemedicine Technical Architecture
Trusted Gateway
Integration National Engine Telemedicine Application Integration MIS MIS Regional / Engine Storage Application District MIS
Telemedicine Telemedicine Core Application Local Applications MIS Medical MIS Devices Workstation
2.5 Telemedicine Workstation
Telemedicine Application Users at the Point of Care and at the Remote Care Provider interact with the Telemedicine Service through a Telemedicine Workstation, which is most usually a Personal Computer (PC), but could be a tablet or mobile device. The Telemedicine Workstation at the Point of Care runs the Local Integration Hub for gathering data from Medical Devices and the MIS, through which all functionality and patient information for Telemedicine should be accessed by the clinical users.
27 Ukraine: Rural Health and Telemedicine
ata nte rati n Tele e icine re t re n ine A licati n
Local Integration MIS Hub Workstation It is recommended that the standard Telemedicine Workstation should be a Personal Computer (PC), connected to the local network through a wired Ethernet connection. This provides the best option in terms of: • cost • performance • physical security Each regional Telemedicine Service is likely to have many hundreds, or thousands, of Telemedicine Workstations, distributed around local Ambulatory Centres (Primary Health Care Centre, Medical Outpatient Centre or Feldsher- Midwife Station) and at District or Regional Hospitals. A key consideration is how those workstations are installed, maintained and supported, especially since many will be at the Point of Care on the local level, situated in remote locations with limited technical expertise or knowledge available. Therefore, it is recommended that ideally, the Workstation should run a virtual desktop, served through a Virtual Desktop Infrastructure running in the Virtual Data Centre. This virtual desktop should have access to the local disk drive and peripheral interfaces (USB, Bluetooth, Zigbee) and all workstation software should be installed on the virtual machine running in the Virtual Data Centre. If this recommendation is followed, then the workstation PC can be a specialised Thin Client with minimal resources and tailored operating system, designed to boot directly to the virtual desktop. The use of Thin Client PCs reduces the cost of the Workstations, simplifies installation and maintenance at the local (remote) level and improves security by ensuring that the local Workstations are only used to run virtual desktops (and hence with no possibility to install software or store data locally).
28 Ukraine: Rural Health and Telemedicine Technical Architecture
Point Telemedicine Remote Care of Care Service Provider
National
Virtual Desktop Infrastructure Data Integration Store Engine Local Integration Regional Hub
Telemedicine Core Applications MIS MIS Workstation
Data Integration Data Integration Store Engine Store Engine Local Integration Local Integration District Hub Hub
Telemedicine Core Telemedicine Core Applications MIS Applications MIS MIS MIS Workstation Workstation
Data Integration Store Engine Local Integration Hub Local Telemedicine Core Applications MIS MIS Workstation
The Virtual Data Centre may run at a single location (e.g. the Regional Hospital) or be distributed across multiple locations (e.g. the Regional Hospital and one or more District Hospitals). The distributed option may be useful for larger regions, where support teams may be located at some District Hospitals, in order to provide support for the Workstations deployed at the Point of Care. In this case, the Virtual Data Centre at the District Hospital can run the Virtual Desktop Infrastructure for the local workstations and instances of the Integration Server, MIS and Telemedicine Applications.
29 Ukraine: Rural Health and Telemedicine
3 FUNCTIONAL PROFILES
Each specific Telemedicine Service will have its own Functional Profile; a configuration of the generic Technical Architecture, adapted to the functional requirements of the service. This section of the Handbook provides Functional Profiles for the most important Telemedicine Services: • Teleconsultation • Telemonitoring of Chronic Diseases ¤¤Hypertension ¤¤Heart failure ¤¤COPD ¤¤Diabetes ¤¤Asthma • Telecardiology ¤¤ECG ¤¤Stethoscope (Heart sounds) • Telediagnosis ¤¤Asynchronous
♦♦Teledermatology ♦♦Telepathology ¤¤Synchronous
♦♦Teledermatology • Teleradiology
♦♦CT ♦♦MRI ♦♦X-ray
30 Ukraine: Rural Health and Telemedicine Functional Profiles
♦♦US ♦♦MG ♦♦OT (Orthopantomography) ♦♦AG (Angiography) ♦♦Tele-obstetrics • Telescreening • Tele-education
Each Functional Profile provides: • a specialisation of the Technical Architecture • an indication of the required hardware and software (from the Product Catalogue) • a Work Breakdown Structure (WBS) for implementation • a description of the Service Delivery Protocol • Reference to relevant care pathways or clinical guidelines, approved at national or regional level
3.1 Stakeholders
The stakeholders in a Telemedicine Service are all those organisations and people and that have an interest or concern in the commissioning, implementation, operation or support of the service. Organisations which are stakeholders include: • Ministry of Health (MoH) • National Health Service of Ukraine (NHS) • National Telemedicine Service Organisation (proposed) • Regional Hospitals
31 Ukraine: Rural Health and Telemedicine
• Telemedicine Service Organisation (proposed) • District Hospitals • Emergency Care and Disaster Centres • Primary Health Care Facilities • Primary Health Care Centre, a Medical Outpatient Centre or a Feldsher- Midwife Station People who are stakeholders include: • Clinician ¤¤Point of Care Clinician the GP, Feldscher, Midwife, Paramedic or other care professional, working at the Point of Care, who provides care or advice to the Patient. ¤¤Expert Clinician a Clinician (usually a specialist) working remotely from the Point of Care. • Patient a person who is the subject of care or advice provided through the Telemedicine Service - must be registered with a GP. • Non-professional Carer a relative, friend or other non-professional person authorised by the Patient to assist them in receiving care or advice through the Telemedicine Service. • Telemedicine Service User a Patient or Non-professional Carer who is provided with care or advice through the Telemedicine Service. • Telemedicine Application User a Clinician, Patient or Non-professional Carer who uses the hardware or software of the Telemedicine Service.
32 Ukraine: Rural Health and Telemedicine Functional Profiles
3.2 Functional Profile – Teleconsultation
Consultation by remote telecommunications, generally for the purpose of diagnosis or treatment of a patient at a site remote from the patient or primary physician [MESH definition].
3.2.1 Scenarios There are several distinct scenarios for Teleconsultation: • Consultation between Point of Care Clinician (without the patient present) and Expert Clinician. • Consultation between Point of Care Clinician (with the patient) and Expert Clinician. • Consultation between Patient at Point of Care and Expert Clinician.
3.2.2 Locations The combination between the location the Point of Care and and the location of the Remote Care Provider can by any of the following:
Point of Care Remote Care Provider District Regional Local District Location Local Regional
33 Ukraine: Rural Health and Telemedicine
Point Telemedicine Remote Care of Care Service Provider
National
Clinican (User) Registry Expert clinician
Teleconsultation Application Video Conference Kit Image Regional MIS Srorage Storage (PACS) Teleconsultation Core Applications MIS Integration Engine MIS Workstation ЕМРІ
Carer(s) Patient Expert clinician
Video District Video Conference Kit Conference Kit
Teleconsultation Core Teleconsultation Core Applications MIS Applications MIS MIS MIS Workstation Workstation
Carer(s) Patient
Video Local Conference Kit
Teleconsultation Core Applications MIS MIS Workstation
3.2.3 Products • Teleconsultation Application • Software for scheduling, initiating and running a Teleconsultation Encounter, including its integration with the MIS. • MIS • The MIS provides a comprehensive patient-centred record of clinical information integrated from other sources or entered directly into the system and made available to authorized users. • Video Conferencing Kit
34 Ukraine: Rural Health and Telemedicine Functional Profiles
• Video, audio and control system for running a consultation between the Point of Care and a Remote Care Provider.
3.2.4 Work Breakdown Structure
WBS – Teleconsultation Work Item Effort Verify network connection (bandwidth and quality) at each site Deliver, unpack and install Video Conferencing Kit at each Point of Care (Ambulatory Centre, District Hospital) Deliver, unpack and install Video Conferencing Kit at each Remote Care Provider (Regional Hospital, District Hospital) Integrate Teleconsultation Application with the MIS Deploy Integrated Teleconsultation Application on virtual desktop Verify operation at test sites Roll out to all sites Organise initial clinic schedules and referral processes Train users Train support staff
3.2.5 Service Delivery Protocol
The pathways described hereafter were formulated assuming that the Teleconsultation Application is embedded in the MIS, and the Video Conferencing Kit is fully integrated with the Teleconsultation Application.
3.2.5.1 Scenario Point of Care Clinician (without patient) – Expert Clinician • Patient and Point of Care Clinician agree on Teleconsultation Encounter; • PoC Clinician schedules the Teleconsultation Encounter with Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information); • The Point of Care Clinician orders the required complementary diagnostic procedures, which should be made available in the MIS prior to the
35 Ukraine: Rural Health and Telemedicine
Teleconsultation Encounter; • The Expert Clinician allocated to the Teleconsultation Encounter needs to be granted access to the Patient record; • The Expert Clinician initiates the Teleconsultation Encounter through the MIS; • During the Teleconsultation Encounter both the Point of Care Clinician and the Expert Clinician can access the MIS to view Patient related information; • Clinical notes may be recorded in the MIS during the Teleconsultation Encounter by either the Point of Care Clinician or the Expert Clinician; • The Expert Clinician ends the Teleconsultation Encounter through the MIS; • Clinical notes related to the Teleconsultation Encounter are saved by the Point of Care Clinician in the MIS for review; • Agreement on the clinical notes of the encounter between the Point of Care Clinician and Expert Clinician; • Clinical notes committed by the Point of Care Clinician to the MIS; • The Point of Care Clinician may inform the Patient on the outcome of the Teleconsultation Encounter.
3.2.5.2 Scenario Point of Care Clinician (with patient) – Expert Clinician • Patient and Point of Care Clinician agree on Teleconsultation Encounter; • PoC Clinician schedules the Teleconsultation Encounter with Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information); • The Point of Care Clinician orders the required complementary diagnostic procedures, which should be made available in the MIS prior to the Teleconsultation Encounter. • The Expert Clinician allocated to the Teleconsultation Encounter needs to be granted access to the Patient record; • The Expert Clinician initiates the Teleconsultation Encounter through the MIS; • During the Teleconsultation Encounter both the Point of Care Clinician and the Expert Clinician can access the MIS to view Patient related information;
36 Ukraine: Rural Health and Telemedicine Functional Profiles
• Clinical notes may be recorded in the MIS during the Teleconsultation Encounter by either the Point of Care Clinician or the Expert Clinician; • The Expert Clinician ends the Teleconsultation Encounter through the MIS; • Clinical notes related to the Teleconsultation Encounter are saved by the Point of Care Clinician in the MIS for review; • Agreement on the clinical notes of the encounter between the Point of Care Clinician and Expert Clinician; • Clinical notes committed by the Point of Care Clinician to the MIS.
3.2.5.3 Scenario Patient – Expert Clinician • Patient and Point of Care Clinician agree on Teleconsultation Encounter; • PoC Clinician schedules the Teleconsultation Encounter with Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information); • The Point of Care Clinician orders the required complementary diagnostic procedures, which should be made available in the MIS prior to the Teleconsultation Encounter. • The Expert Clinician allocated to the Teleconsultation Encounter needs to be granted access to the Patient record; • The Expert Clinician initiates the Teleconsultation Encounter through the MIS; • During the Teleconsultation Encounter the Expert Clinician can access the MIS to view Patient related information; • Clinical notes may be recorded in the MIS during the Teleconsultation Encounter by the Expert Clinician; • The Expert Clinician ends the Teleconsultation Encounter through the MIS; • Clinical notes related to the Teleconsultation Encounter are saved by the Expert Clinician in the MIS for review; • Agreement on the clinical notes of the encounter between the Point of Care Clinician and Expert Clinician; • Clinical notes committed by the Point of Care Clinician to the MIS.
37 Ukraine: Rural Health and Telemedicine
3.2.6 Care Pathways
The Service Delivery Protocol should be integrated with the nationally or regionally approved care pathways and/or clinical guidelines where these are available.
3.3 Functional Profile – Telemonitoring of Chronic Conditions
Telemonitoring of chronic conditions involves continuous data recording of patient measurements as part of their daily routine and/or monitoring of the patient in their own home. 3.3.1 Scenarios There are two distinct scenarios for Telemonitoring of Chronic Conditions: • Synchronous. • Asynchronous. 3.3.2 Locations The combination between the location the Point of Care and and the location of the Remote Care Provider can by any of the following:
Point of Care Remote Care Provider District Regional Local District Location Local Regional
38 Ukraine: Rural Health and Telemedicine Functional Profiles
Point Telemedicine Remote Care of Care Service Provider
National
Clinican (User) Registry Expert clinician
Telemonitoring Application
Image Regional MIS Srorage Storage (PACS) Telemonitoring Core Applications MIS Integration Engine MIS Workstation ЕМРІ
Carer(s) Patient Expert clinician
Video District Conference Kit
Telemonitoring Core Telemonitoring Core Applications MIS Applications MIS MIS MIS Workstation Workstation
Carer(s) Patient
Video Local Conference Kit
Telemonitoring Core Applications MIS MIS Workstation
39 Ukraine: Rural Health and Telemedicine
3.3.3 Products • Telemonitoring Application Software for integration of the Telemonitoring Device with the MIS, including data processing, interpretation, and display. • MIS The MIS provides a comprehensive patient centred record of clinical information integrated from other sources, or entered directly into the system, and made available to authorized users. • Digital Sphygmomanometer Medical device which measures the blood pressure, including blood pressure data streaming and integration with the Telemonitoring Application. • Digital Scale Medical device for measuring body weight, including weight data streaming and integration with the Telemonitoring Application. • Digital Spirometer Medical device for measuring the volume of air inspired and expired by the lungs, including medical data streaming and integration with the Telemonitoring Application. • Digital Oximeter Medical device for measuring the proportion of oxygenated haemoglobin in the blood, including medical data streaming and integration with the Telemonitoring Application. • Digital Glucometer Medical device which measures the concentration of glucose in the blood, including glucose data streaming and integration with the Telemonitoring Application.
40 Ukraine: Rural Health and Telemedicine Functional Profiles
3.3.4 Work Breakdown Structure
WBS – Telemonitoring Work Item Effort Verify existing set up for Teleconsultation at each site Deliver, unpack and set up Telemonitoing devices at each Point of Care Verify data transfer from devices to Local Integration Hub Configure Local Integration Hub for each device (data transformation and routing). This is done on the Virtual Desktop served from the Virtual Data Centre. Configure Integration Engine in Virtual Data Centre (data transformation and routing to MIS). Integrate Telemonitoing Application with the MIS Deploy Integrated Telemonitoing Application on virtual desktop Verify operation at test sites Roll out to all sites Organise initial clinic schedules and referral processes Train users Train support staff
3.3.5 Service Delivery Protocol
3.3.5.1 Scenario Synchronous 1. Patient and Point of Care Clinician agree on the Telemonitoring Encounter; 2. Point of Care Clinician schedules the Telemonitoring Encounter in the MIS. (Note: The Patient needs to be identified in the encounter booking information);
41 Ukraine: Rural Health and Telemedicine
3. Point of Care Clinician trains the Patient in the use of the Telemonitoring Medical Device; 4. Patient measurements recorded by the Telemonitoring Device are received by the Telemonitoring Application. The Telemonitoring Application sends the patient data to the MIS (Note the Patient and the Telemonitoring Encounter should be identified in all the transactions between systems); 5. The Expert Clinician allocated to the Telemonitoring Encounter needs to be granted access to the Patient record; 6. During the Telemonitoring Encounter the Expert Clinician can access the MIS to view Patient related information; 7. The Expert Clinician views the telemonitoring recorded data through the MIS; 8. Clinical notes may be recorded in the MIS during the Telemonitoring Encounter by the Expert Clinician; 9. Clinical notes related to the Telemonitoring Encounter are saved by the Expert Clinician in the MIS for review; 10. Agreement on the clinical notes by the Expert Clinician; 11. Clinical notes committed by the Expert Clinician to the MIS. 12. The Point of Care Clinician may inform the Patient on the outcome of the Telemonitoring Encounter.
3.3.5.2 Scenario Asynchronous 1. Patient and Point of Care Clinician agree on the Telemonitoring Encounter; 2. Point of Care Clinician schedules the Telemonitoring Encounter in the MIS. (Note: The Patient needs to be identified in the encounter booking information); 3. Point of Care Clinician trains the patient in the use of the Telemonitoring Medical Device; 4. Patient measurements are recorded by the Telemonitoring Device; 5. Point of Care Clinician retrieves the patient data from the Telemonitoring
42 Ukraine: Rural Health and Telemedicine Functional Profiles
Device. Patient data is received by the Telemonitoring Application. The Telemonitoring Application sends the patient data to the MIS (Note the patient and the Telemonitoring Encounter should be identified in all the transactions between systems); 6. The Point of Care Clinician views the telemonitoring recorded data through the MIS; 7. Clinical notes may be recorded in the MIS during the Telemonitoring Encounter by the Point of Care Clinician; 8. Clinical notes related to the Telemonitoring Encounter are saved by the Point of Care Clinician in the MIS for review; 9. Agreement on the clinical notes by the Point of Care Clinician; 10. Clinical notes committed by the Point of Care Clinician to the MIS. 11. The Point of Care Clinician may inform the Patient on the outcome of the Telemonitoring Encounter.
3.3.6 Care Pathways
The Service Delivery Protocol should be integrated with the nationally or regionally approved care pathways and/or clinical guidelines where these are available.
3.4 Functional Profile – Telecardiology
Telecardiology is a Teleconsultation Encounter which involves the digital transmission of cardiology related information between the Point of Care and the Remote Care Provider.
3.4.1 Scenarios There are two distinct scenarios for Telemonitoring of Chronic Conditions: • Synchronous Outpatient; • Synchronous Emergency;
43 Ukraine: Rural Health and Telemedicine
3.4.2 Locations The combination between the location the Point of Care and and the location of the Remote Care Provider can by any of the following:
Point of Care Remote Care Provider District Regional Local District Location Local Regional
Point Telemedicine Remote Care of Care Service Provider
National
Clinican (User) Registry Expert clinician
Teleсardiology Teleconsultation Application Application Video Conference Kit Image Regional MIS Srorage Storage (PACS) Teleсardiology App Core Integration Engine Teleconsultation App MIS MIS ЕМРІ Workstation
Carer(s) Patient Expert clinician
District Medical Devices Video Video Conference Kit Conference Kit
Teleсardiology App Core Teleсardiology App Core Teleconsultation App MIS Teleconsultation App MIS MIS MIS Workstation Workstation
Carer(s) Patient
Medical Devices Local Video Conference Kit
Teleсardiology App Core Teleconsultation App MIS MIS Workstation
44 Ukraine: Rural Health and Telemedicine Functional Profiles
3.4.3 Products
• Teleconsultation Application Software for scheduling, initiating and running a Teleconsultation Encounter, including its integration with the MIS. • Video Conferencing Kit Video, audio and control system for running a consultation between the Point of Care and a Remote Care Provider. • Telecardiology Application Software for integration of the Cardiology Medical Device with the MIS, including data processing, interpretation, and display. • MIS The MIS provides a comprehensive patient-centred record of clinical information integrated from other sources or entered directly into the system, and made available to authorized users. • Multi-lead Digital ECG Medical device which captures the electrical activity of the heart, including electrocardiographic data streaming and integration with the Telecardiology Application. • Digital Stethoscope Medical device which detects sounds produced by the heart, including auscultated sound data streaming and integration with the Telecardiology Application.
45 Ukraine: Rural Health and Telemedicine
3.4.4 Work Breakdown Structure
WBS – Telecardiology Work Item Effort Verify existing set up for Teleconsultation at each site Deliver, unpack and set up Telecardiology devices at each Point of Care Verify data transfer from devices to Local Integration Hub Configure Local Integration Hub for each device (data transformation and routing). This is done on the Virtual Desktop served from the Virtual Data Centre. Configure Integration Engine in Virtual Data Centre (data transformation and routing to MIS). Integrate Telecardiology Application with the MIS Deploy Integrated Telecardiology Application on virtual desktop Verify operation at test sites Roll out to all sites Organise initial clinic schedules and referral processes Train users Train support staff
3.4.5 Service Delivery Protocol The pathways described hereafter were formulated assuming that the Telecardiology Application is embedded in the MIS, and the Cardiology Medical Device is fully integrated with the Telecardiology Application.
3.4.5.1 Scenario Synchronous outpatient 1. Patient and Point of Care Clinician agree on Telecardiology Encounter;
46 Ukraine: Rural Health and Telemedicine Functional Profiles
2. Point of Care Clinician schedules the Telecardiology Encounter with Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information); 3. The Point of Care Clinician orders the required complementary diagnostic procedures, which should be made available in the MIS prior to the Telecardiology Encounter. 4. The Expert Clinician allocated to the Telecardiology Encounter needs to be granted access to the Patient record; 5. The Expert Clinician initiates the Teleconsultation Encounter through the MIS; 6. The Point of Care Clinician enables the Telecardiology Application through the MIS; 7. During the Telecardiology Encounter both the Point of Care Clinician and the Expert Clinician can access the MIS to view Patient related information; 8. Clinical notes may be recorded in the MIS during the Telecardiology Encounter by either the Point of Care Clinician or the Expert Clinician; 9. The Point of Care Clinician disables the Telecardiology Application through the MIS; 10. The Expert Clinician ends the Teleconsultation Encounter through the MIS; 11. Clinical notes related to the Telecardiology Encounter are saved by the Point of Care Clinician in the MIS for review; 12. Agreement on the clinical notes of the Telecardiology Encounter between the Point of Care Clinician and Expert Clinician; 13. Clinical notes committed by the Point of Care Clinician to the MIS; 14. The Point of Care Clinician may inform the Patient on the outcome of the Telecardiology Encounter.
3.4.5.2 Scenario Synchronous emergency 1. The Point of Care Clinician initiates the emergency Teleconsultation Encounter; 2. The Point of Care Clinician enables the Emergency Telecardiology Application;
47 Ukraine: Rural Health and Telemedicine
3. The Expert Clinician allocated to the emergency Telecardiology Encounter needs to be granted access to the Patient record; 4. During the emergency Telecardiology Encounter the Expert Clinician can access the MIS to view Patient related information; 5. The Point of Care Clinician disables the Emergency Telecardiology Application; 6. The Point of Care Clinician ends the emergency Teleconsultation Encounter; 7. Clinical notes related to the emergency Telecardiology Encounter should be recorded in the MIS by the Expert Clinician; 8. Clinical notes related to the emergency Telecardiology Encounter are saved by the Expert Clinician in the MIS for review; 9. Agreement on the clinical notes by the Expert Clinician; 10. Clinical notes committed by the Expert Clinician to the MIS.
3.4.6 Care Pathways
The Service Delivery Protocol should be integrated with the nationally or regionally approved care pathways and/or clinical guidelines where these are available.
3.5 Functional Profile – Telediagnosis Telediagnosis is a diagnosis that is made at a Remote Care Provider and is based on the evaluation of data transmitted from instruments that monitor the patient at the Point of Care.
3.5.1 Scenarios
There are two distinct scenarios for Telemonitoring of Chronic Conditions: • Synchronous Diagnosis/Opinion Expert Clinician; • Synchronous Point of Care Clinician (with Patient) – Expert Clinician;
48 Ukraine: Rural Health and Telemedicine Functional Profiles
3.5.2 Locations
The combination between the location the Point of Care and and the location of the Remote Care Provider can by any of the following:
Point of Care Remote Care Provider District Regional Local District Location Local Regional
Point Telemedicine Remote Care of Care Service Provider
Telemedicine Carer(s) Service Organisation Directory ЕМРІ Email Services Services Healthcare Patient Provider Organisation
Service Community Applications Care Control Control Medical Acoess Acoess (Mobile) Devices Monitoring Medical And Data Devices Collection MIS PACS Specialist Storage Storage Systems, Tools and Equipment
Data Іntegration Integration Integration Data Store Engine Engine Engine Store Local Integration Local Integration Hub Hub
Virtual Telemedicine Core Desktop Telemedicine Core Applications MIS Infrastructure Applications MIS MIS MIS Work station Work station Network Network
49 Ukraine: Rural Health and Telemedicine
3.5.3 Products • Teleconsultation Application Software for scheduling, initiating and running a Teleconsultation Encounter, including its integration with the MIS. • Video Conferencing Kit Video, audio and control system for running a consultation between the Point of Care and a Remote Care Provider. • Telediagnosis Application Software for integration of the Diagnostic Medical Devices with the MIS, including data processing, interpretation, and display. • MIS The Medical Information System system provides a comprehensive patient- centred record of clinical information integrated from other sources or entered directly into the system, and made available to authorized users. • Digital Dermatoscope Medical device which captures skin images/video, including data streaming and integration with the Telediagnosis Application. • Digital Image capture system (Telepathology) Image and video system which enables the retrieval of pathology data from medical devices, including integration with the Telediagnosis Application.
50 Ukraine: Rural Health and Telemedicine Functional Profiles
3.5.4 Work Breakdown Structure
WBS - Telediagnosis Work Item Effort Verify existing set up for Teleconsultation at each site Deliver, unpack and set up Telediagnosis devices at each Point of Care Verify data transfer from devices to Local Integration Hub Configure Local Integration Hub for each device (data transformation and routing). This is done on the Virtual Desktop served from the Virtual Data Centre. Configure Integration Engine in Virtual Data Centre (data transformation and routing to MIS). Integrate Telediagnosis Application with the MIS Deploy Integrated Telediagnosis Application on virtual desktop Verify operation at test sites Roll out to all sites Organise initial clinic schedules and referral processes Train users Train support staff
51 Ukraine: Rural Health and Telemedicine
3.5.5 Service Delivery Protocol The pathways described hereafter were formulated assuming that the Telediagnosis Application is embedded in the MIS, and the Diagnostic Medical Devices are fully integrated with the Telediagnosis Application.
3.5.5.1 Scenario Diagnosis/Opinion Expert Clinician
1. Point of Care Clinician enables the Telediagnosis Application through the MIS; 2. Point of Care Clinician records the data retrieved from the Diagnostic Medical Devices in the MIS, including referral notes; 3. Point of Care Clinician disables the Telediagnosis Application through the MIS; 4. Point of Care Clinician schedules the Telediagnosis Encounter with Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information); 5. The Point of Care Clinician orders the required complementary diagnostic procedures, which should be made available in the MIS prior to the Telediagnosis Encounter. 6. The Expert Clinician allocated to the Telediagnosis Encounter needs to be granted access to the Patient record; 7. During the Telediagnosis Encounter the Expert Clinician can access the MIS to view Patient related information; 8. Clinical notes may be recorded in the MIS during the Telediagnosis Encounter by the Expert Clinician; 9. Clinical notes related to the Telediagnosis Encounter are saved by the Expert Clinician in the MIS for review; 10. Agreement on the clinical notes of the Telediagnosis Encounter by the Expert Clinician; 11. Clinical notes committed by the Expert Clinician to the MIS; 12. The Point of Care Clinician may inform the Patient on the outcome of the Telediagnosis Encounter.
52 Ukraine: Rural Health and Telemedicine Functional Profiles
3.5.5.2 Scenario Point of Care Clinician (with Patient) – Expert Clinician
1. Patient and Point of Care Clinician agree on Telediagnosis Encounter; 2. Point of Care Clinician schedules the Telediagnosis Encounter with Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information); 3. The Point of Care Clinician orders the required complementary diagnostic procedures, which should be made available in the MIS prior to the Telediagnosis Encounter. 4. The Expert Clinician allocated to the Telediagnosis Encounter needs to be granted access to the Patient record; 5. The Expert Clinician initiates the Telediagnosis Encounter through the MIS; 6. The Point of Care Clinician enables the Telediagnosis Application through the MIS; 7. The Point of Care Clinician records the data retrieved from the Diagnostic Medical Devices in the MIS 8. During the Telediagnosis Encounter both the Point of Care Clinician and the Expert Clinician can access the MIS to view Patient related information; 9. Clinical notes may be recorded in the MIS during the Telediagnosis Encounter by either the Point of Care Clinician or the Expert Clinician; 10. The Point of Care Clinician disables the Telediagnosis Application through the MIS; 11. The Expert Clinician ends the Telediagnosis Encounter through the MIS; 12. Clinical notes related to the Telediagnosis Encounter are saved by the Point of Care Clinician in the MIS for review; 13. Agreement on the clinical notes of the Telediagnosis Encounter between the Point of Care Clinician and Expert Clinician; 14. Clinical notes committed by the Point of Care Clinician to the MIS; 15. The Point of Care Clinician may inform the Patient on the outcome of the Telediagnosis Encounter.
53 Ukraine: Rural Health and Telemedicine
3.5.6 Care Pathways
The Service Delivery Protocol should be integrated with the nationally or regionally approved care pathways and/or clinical guidelines where these are available.
3.6 Functional Profile – Teleradiology
The electronic transmission of medical images from the Point of Care to a Remote Care Provider for the purposes of interpretation and/or consultation.
3.6.1 Scenarios There are two distinct scenarios for Telemonitoring of Chronic Conditions: • Synchronous Diagnosis/Opinion Expert Clinician; • Synchronous Point of Care Clinician (with Patient) – Expert Clinician;
3.6.2 Locations The combination between the location the Point of Care and and the location of the Remote Care Provider can by any of the following:
Point of Care Remote Care Provider District Regional Local District Location Local Regional
54 Ukraine: Rural Health and Telemedicine Functional Profiles
Point Telemedicine Remote Care of Care Service Provider
National
Clinican (User) Registry Expert clinician
Teleсardiology Teleconsultation Application Application Video Conference Kit Image Regional MIS Srorage Storage (PACS) Teleсardiology App Core Integration Engine Teleconsultation App MIS MIS ЕМРІ Workstation
Carer(s) Patient Expert clinician
Video District Video Conference Kit Conference Kit
Teleсardiology App Core Image Teleсardiology App Core MIS MIS Teleconsultation App Srorage Teleconsultation App MIS MIS (PACS) Workstation Workstation
Carer(s) Patient
Local Video Conference Kit
Teleсardiology App Core Teleconsultation App MIS MIS Workstation
3.6.3 Products • Teleconsultation Application Software for scheduling, initiating and running a Teleconsultation Encounter, including its integration with the MIS. • Video Conferencing Kit Video, audio and control system for running a consultation between the Point of Care and a Remote Care Provider. • Teleradiology Application Software that enables the near real-time viewing, processing and annotation of medical images.
55 Ukraine: Rural Health and Telemedicine
• MIS The MIS provides a comprehensive patient-centred record of clinical information integrated from other sources or entered directly into the system, and made available to authorized users. • Radiology Information System and Picture Archiving and Communications System (RIS/PACS) Information systems, usually computer-assisted, designed to store, manipulate, and retrieve information for planning, organizing, directing, and controlling administrative activities associated with the provision and utilization of radiology services and facilities.
3.6.4 Work Breakdown Structure
WBS – Telediagnosis Work Item Effort Verify existing set up for Teleconsultation at each site Verify operation of PACS/RIS at each site Configure dedicated Teleradiology PACS in the Virtual Data Centre, if that option is chosen for viewing of diagnostic images Configure Integration Engine in Virtual Data Centre to transfer diagnostic images to dedicated Teleradiology PACS, if that is configured Integrate Teleradiology Application with the MIS so that diagnostic images can be viewed though the MIS Deploy Integrated Teleradiology Application on virtual desktop Verify operation at test sites Roll out to all sites Organise initial clinic schedules and referral processes Train users Train support staff Train support staff
56 Ukraine: Rural Health and Telemedicine Functional Profiles
3.6.5 Service Delivery Protocol The pathways described hereafter were formulated assuming that the Teleradiology Application is embedded in the MIS, and the diagnostic images are viewed through the RIS/PACS at the District or Regional Hospital. Alternatively, images may be transferred from the local RIS/PACS to a dedicated RIS/PACS used solely for Teleradiology.
3.6.5.1 Scenario Point of Care Clinician (with the patient) – Expert Clinician
1. Patient and Point of Care Clinician agree on the Teleradiology Encounter; 2. PoC Clinician schedules the Teleradiology Encounter with Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information); 3. The Point of Care Clinician orders the required complementary diagnostic procedures, which should be made available in the MIS prior to the Teleradiology Encounter. 4. The Expert Clinician allocated to the Teleradiology Encounter needs to be granted access to the Patient record; 5. The Expert Clinician initiates the Teleradiology Encounter through the MIS; 6. The Point of Care Clinician enables the Teleradiology Application; 7. During the Teleradiology Encounter both the Point of Care Clinician and the Expert Clinician can access the MIS to view Patient related information; 8. Clinical notes may be recorded in the MIS during the Teleradiology Encounter by either the Point of Care Clinician or the Expert Clinician; 9. The Point of Care Clinician disables the Teleradiology Application; 10. The Expert Clinician ends the Teleradiology Encounter through the MIS; 11. Clinical notes related to the Teleradiology Encounter are saved by the Point of Care Clinician in the MIS for review; 12. Agreement on the clinical notes of the encounter between the Point of Care Clinician and Expert Clinician; 13. Clinical notes committed by the Point of Care Clinician to the MIS.
57 Ukraine: Rural Health and Telemedicine
3.6.5.2 Scenario Reporting by Expert Clinician (Elective and Emergency)
There is an IHE Remote Reporting for Imaging (Teleradiology) proposal, however, it is considered that the best solution is to merge intra-mural and extra-mural workflows through an integrated, interoperable and distributed architecture. If a national Private Health Network is in place, the local PACS can ask C-MOVE SCP to send the images to a Remote Location and follow the IHE Import Reconciliation Workflow, to consolidate the information sent from the Remote Location in the local PACS. Ideally, the communication between the local PACS and the Remote Location (Workstation) should be mediated through a PACS dedicated to Teleradiology. Alternatively, VPN connections can be used.
3.6.6 Care Pathways
The Service Delivery Protocol should be integrated with the nationally or regionally approved care pathways and/or clinical guidelines where these are available.
3.7 Functional Profile – Telescreening Services
The use of Telemedicine for interpretation of data from mobile screening units. The most common form of telescreening is for diabetic retinopathy, but can also be used for mobile breast cancer screening (mammography) units.
3.7.1 Scenarios
There are two distinct scenarios for Telescreening: • Generating DICOM based data; • Generating non-DICOM based data.
58 Ukraine: Rural Health and Telemedicine Functional Profiles
3.7.2 Locations
The combination between the location the Point of Care and and the location of the Remote Care Provider can by any of the following:
Point of Care Remote Care Provider District Regional Local District Location Local Regional
Point Telemedicine Remote Care of Care Service Provider
National
Clinican (User) Registry Expert clinician
Telescreening Application
Image Regional MIS Srorage Storage (PACS) Telescreening Core Application MIS Integration Engine MIS Workstation ЕМРІ
Carer(s) Patient Expert clinician
Video District Conference Kit
Telescreening Core Telescreening Core Application MIS Image Application MIS MIS Srorage MIS Workstation (PACS) Workstation
Carer(s) Patient
Video Local Conference Kit
Telescreening Core Application MIS MIS Workstation
59 Ukraine: Rural Health and Telemedicine
3.7.3 Products
• Telescreening Application Software for integration of Telescreening generated data with the MIS, including data processing, interpretation, and display. • MIS The MIS provides a comprehensive patient-centred record of clinical information integrated from other sources or entered directly into the system, and made available to authorized users. • Radiology Information System and Picture Archiving and Communications System (RIS/PACS) Information systems, usually computer-assisted, designed to store, manipulate, and retrieve information for planning, organizing, directing, and controlling administrative activities associated with the provision and utilization of radiology services and facilities. • Digital Ophthalmoscope Medical device for inspecting the retina and other parts of the eye, including the streaming of ophthalmoscopic data and integration with the Telescreening Application. • Other screening devices Medical devices integrated with the Telescreening Application.
60 Ukraine: Rural Health and Telemedicine Functional Profiles
3.7.4 Work Breakdown Structure
WBS – Telediagnosis Work Item Effort Verify existing set up for Teleconsultation at each site Verify operation of PACS/RIS, if required for screening Configure dedicated Telescreening PACS in the Virtual Data Centre, if that option is chosen for viewing of images in the monitoring encounter Configure Integration Engine in Virtual Data Centre to transfer diagnostic images to dedicated Telescreening PACS, if that is configured Integrate Telescreening Application with the MIS so that diagnostics images can be viewed though the MIS Deploy Integrated Telescreening Application on virtual desktop Verify operation at test sites Roll out to all sites Organise initial clinic schedules and referral processes Train users Train support staff Train support staff
3.7.5 Service Delivery Protocol
3.7.5.1 Scenario Telescreening generating DICOM based data
1. PoC Clinician schedules the Telescreening Encounter with the Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information);
61 Ukraine: Rural Health and Telemedicine
2. The Point of Care Clinician commits the patient medical images selected for diagnosis to the Telescreening dedicated PACS. 3. The Expert Clinician allocated to the Telescreening Encounter needs to be granted access to the Patient record; 4. During the Telescreening Encounter both the Point of Care Clinician and the Expert Clinician can access the MIS to view Patient related information; 5. Clinical notes may be recorded in the MIS during the Telescreening Encounter by either the Point of Care Clinician or the Expert Clinician; 6. Clinical notes related to the Telescreening Encounter are saved by the Point of Care Clinician in the MIS for review; 7. Agreement on the clinical notes of the Telescreening Encounter between the Point of Care Clinician and Expert Clinician; 8. Clinical notes committed by the Point of Care Clinician to the MIS. 9. The Point of Care Clinician may inform the Patient on the outcome of the Telescreening Encounter.
3.7.5.2 Scenario Telescreening generating non-DICOM based data
1. PoC Clinician schedules the Telescreening Encounter with Expert Clinician in the MIS. (Note: The Patient needs to be identified in the encounter booking information); 2. The Expert Clinician allocated to the Telescreening Encounter needs to be granted access to the Patient record; 3. The Expert Clinician initiates the Teleconsultation Encounter through the MIS; 4. The Point of Care Clinician enables the Telescreening Application through the MIS; 5. During the Telescreening Encounter both the Point of Care Clinician and the Expert Clinician can access the MIS to view Patient related information; 6. Clinical notes may be recorded in the MIS during the Telescreening Encounter by either the Point of Care Clinician or the Expert Clinician;
62 Ukraine: Rural Health and Telemedicine Functional Profiles
7. The Point of Care Clinician disables the Telescreening Application through the MIS; 8. The Expert Clinician ends the Telescreening Encounter through the MIS; 9. Clinical notes related to the Telescreening Encounter are saved by the Point of Care Clinician in the MIS for review; 10. Agreement on the clinical notes of the Telescreening Encounter between the Point of Care Clinician and Expert Clinician; 11. Clinical notes committed by the Point of Care Clinician to the MIS; 12. The Point of Care Clinician may inform the Patient on the outcome of the Telescreening Encounter.
3.7.6 Care Pathways
The Service Delivery Protocol should be integrated with the nationally or regionally approved care pathways and/or clinical guidelines where these are available.
3.8 Functional Profile – Tele-education
Tele-education has been used for many years to deliver continuing education programmes to rural healthcare professionals. The main modes are audio, video and computer. Audio technologies involve the transmission of the spoken word (voice) between learners and instructors, either synchronously or asynchronously. In this profile, the Expert Clinician performs the role of the instructor. For asynchronous Tele-education, the instructor has pre-recorded the session, and so is not present during the encounter.
3.8.1 Scenarios
There are two distinct scenarios for Tele-education: • Synchronous; • Asynchronous;
63 Ukraine: Rural Health and Telemedicine
3.8.2 Locations
The combination between the location the Point of Care and and the location of the Remote Care Provider can by any of the following:
Point of Care Remote Care Provider District Regional Local District Location Local Regional
Point Telemedicine Remote Care of Care Service Provider
National
Clinican (User) Registry Expert clinician
Telemedicine Tele-education Application Application Video Conference Kit Image Regional MIS Srorage Storage Education Sessiom (PACS) Telemedicine App Core Integration Engine Tele-education App MIS MIS ЕМРІ Workstation
Carer(s) Patient Expert clinician
Video District Video Conference Kit Conference Kit
Telemedicine App Core Telemedicine App Core Tele-education App MIS Tele-education App MIS MIS MIS Workstation Workstation
Carer(s) Patient
Local Video Conference Kit
Telemedicine App Core Tele-education App MIS MIS Workstation
64 Ukraine: Rural Health and Telemedicine Functional Profiles
3.8.3 Products
• Video Conferencing Kit Video, audio and control system for running a consultation between the Point of Care and a Remote Care Provider. • Tele-education Application Software which provides Point of Care Clinicians to access health education and support, including personalized education materials, coaching, online discussions, provider trainings. • MIS (Education session) The MIS provides a comprehensive patient-centred record of clinical information integrated from other sources or entered directly into the system, and made available to authorized users. • Telemedicine Application (Education session) Software for integration of the Telemedicine solution object of training with the MIS, including data processing, interpretation, and display.
3.8.4 Work Breakdown Structure
WBS – Telediagnosis Work Item Effort Verify existing set up for Teleconsultation at each site Deploy Tele-education Application on virtual desktop (not integrated with the MIS, but may be launched from it) Verify operation at test sites Roll out to all sites Train users Train support staff
65 Ukraine: Rural Health and Telemedicine
3.8.5 Service Delivery Protocol 1. PoC Clinician and Expert Clinician agree on Tele-education; 2. Expert Clinician schedules the Tele-education Session in the Tele-education Application; 3. The Expert Clinician initiates the Tele-education Session through the Tele- education Application; 4. The Expert Clinician initiates the Telemedicine Application through the MIS; 5. The Expert Clinician ends the Telemedicine Application through the MIS; 6. The Expert Clinician ends the Tele-education Session through the Tele- education Application.
3.8.6 Care Pathways
The Service Delivery Protocol should be integrated with the nationally or regionally approved care pathways and/or clinical guidelines where these are available.
66 Ukraine: Rural Health and Telemedicine Standards
4 STANDARDS
The use of open information standards is vital to the success of Telemedicine services. The base standards profile adopted is the Continua Alliance Guidelines (CDG) which are published by the Personal Connected Health Alliance (PCH Alliance). The Continua Alliance Guidelines define a reference architecture which defines the data that may or must be transmitted between devices at the application protocol and transport layers, following the Open Systems Interconnection seven layer reference model.
Layer Description High-level APIs, including resource 7. Application sharing, remote file access Translation of data between a networking service and an application; including 6. Presentation character encoding, data compression and encryption/decryption Host Managing communication sessions, i.e. continuous exchange of information Layers 5. Session in the form of multiple back-and-forth transmissions between two nodes Reliable transmission of data segments between points on a network, including 4. Transport segmentation, acknowledgement and multiplexing Structuring and managing a multi-node 3. Network network, including addressing, routing Media and traffic control Layers Reliable transmission of data frames 2. Data Link between two nodes connected by a physical layer Transmission and reception of raw bit 1. Physical streams over a physical medium
67 Ukraine: Rural Health and Telemedicine
The Continua Alliance Guidelines provide a profile of open, international standards to be used at each point in the reference architecture of Telemedicine. This Handbook further refines those standards to recommend the best practice for the Technical Architecture of the Telemedicine Service. The Guidelines aim to ensure interoperability between sensors, hubs, service platforms, and Electronic Health Record systems manufactured by different vendors. The reference architecture consists of four components and the guidelines are focussed on the specification of the interfaces between them, in order to enable interoperability; hence there are three sets of interface specifications. The terminology used in the guidelines and reference architecture is slightly different from the terminology in this Handbook, due to the difference in focus between Telemedicine (this Handbook) and Telehealth (the Continua Design Guidelines). 1. Personal Health Devices – such as a blood pressure meter, pedometer or personal alarm. These are the Medical Devices running at the Point of Care. 2. Personal Health Gateway – which may be a cell phone, PC, or specialist device. This is the Local Integration Hub running on the Workstation at the Point of Care. 3. Health & Fitness Server – typically a Telehealth remote monitoring service platform. This is the Telemedicine Service running in the Virtual Data Centre at the Regional (and District) hospitals. 4. Health Information System – typically a physician's electronic health record. This is the MIS and PACS systems holding the electronic health record, running in the Virtual Data Centre at the Regional (and District) hospitals. The guidelines set out the requirements for the interfaces between these components; three sets of standards are defined for the three types of interface in the reference architecture, organised as shown in the Figure. • Personal Health Devices Interfaces • Services Interfaces • Healthcare Information System Interfaces
68 Ukraine: Rural Health and Telemedicine Standards
Point Telemedicine Remote Care of Care Service Provider
Telemedicine Carer(s) Service Organisation Directory ЕМРІ Email Services Services Healthcare Patient Provider Organisation
Service Community Applications Care Control Control Medical Acoess Acoess (Mobile) Devices Medical Monitoring His Interface Devices And Data Collection Specialist Systems, Tools MIS PACS and Equipment Storage Storage Health Devices Interface Health Devices Interface His Interface
Data Іntegration Integration Integration Data Store Engine Engine Engine Store Local Integration Local Integration Hub Hub Services Interface Services Interface
Virtual Telemedicine Core Desktop Telemedicine Core Applications MIS Infrastructure Applications MIS MIS MIS Work station Work station
Network Network
Products used in the Telemedicine Service must conform to these standards, to ensure interoperability and to allow products from different vendors to be interchangeable, to fulfil the same role in the Technical Architecture. Testing of standards compliance is therefore a key part of the verification process for products listed in the Product Catalogue.
69 Ukraine: Rural Health and Telemedicine
4.1 Personal Health Devices Interface The Personal Health Devices Interface layer operates between the Medical Devices and the Local Integration Hub. This integration engine can be then be configured to handle each of the standard data formats received through the interface. The Personal Health Devices Interface employs the IEEE 11073 family of standards for data format and exchange between the Medical Device and the Local Integration Hub over Bluetooth BR/EDR, NFC, USB, or ZigBee. Data transferred via the Bluetooth Low Energy profile implementations can also be transcoded into IEEE 11073 compatible data. The IEEE 11073 Personal Health Device family of standards is developed through collaboration between the IEEE and the Personal Connected Health Alliance. Information on the standards can be found online at http://11073.org and is available in the publication: CDG H.811 “Personal Health Devices Interface Design Guidelines”. The IEEE 11073 standards are based around a single "framework" standard which defines the generic data types, message types and communication model for exchanging data between Medical Devices and other components of the Telemedicine service: • IEEE 11073-20601 - Application profile - Optimized exchange protocol Each specific type of device then has a specialisation standard which defines the data formats for that device: • IEEE 11073-10404 - Device specialization - Pulse Oximeter • IEEE 11073-10407 - Device specialization - Blood Pressure Monitor • IEEE 11073-10408 - Device specialization - Thermometer • IEEE 11073-10415 - Device specialization - Weighing Scale • IEEE 11073-10417 - Device specialization - Glucose Meter • IEEE 11073-10420 - Device specialization - Body composition analyser • IEEE 11073-10421 - Device specialization - Peak flow • IEEE 11073-10441 - Device specialization - Cardiovascular fitness and activity monitor • IEEE 11073-10442 - Device specialization - Strength fitness equipment
70 Ukraine: Rural Health and Telemedicine Standards
• IEEE 11073-10471 - Device specialization - Independent living activity hub • IEEE 11073-10472 - Device specialization - Medication monitor • IEEE 11073-10406 - Device specialization - Basic ECG (1 to 3-lead) • IEEE 11073-10413 - Device specialization - Respiration rate monitor • IEEE 11073-10418 - Device specialization - INR (blood coagulation) • IEEE 11073-10419 - Device specialization - Insulin pump • IEEE 11073-10425 - Device specialization - Continuous glucose monitor • IEEE 11073-10427 - Device specialization - Power status monitor of personal health devices
4.1.1 NFC Interface
Near-field Communication (NFC) is a set of communication protocols that enable two electronic devices, one of which is usually a portable device such as a smartphone, to establish communication by bringing them within 4 cm of each other.
4.1.2 USB Interface
Universal Serial Bus (USB) is an industry standard that establishes specifications for cables, connectors and protocols for connection, communication and power supply between personal computers and their peripheral devices.
4.1.3 Zigbee Interface
Zigbee is an IEEE 802.15.4-based specification for a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios, such as for home automation, medical device data collection, and other low-power low-bandwidth needs, designed for small scale projects which need wireless connection. Hence, Zigbee is a low-power, low data rate, and close proximity (i.e., personal area) wireless ad hoc network.
71 Ukraine: Rural Health and Telemedicine
4.1.4 Bluetooth Interface
The connectivity in the Bluetooth BR/EDR interface (BR/EDR-IF) is adapted to satisfy three requirements that are uniform across the application domains serviced by the Medical Devices: bidirectional sensor control, bidirectional sensor information exchange, and appropriate linkage between a Medical Device and the Local Integration Hub. The interface is further structured into three distinct layers, with appropriate standards representing the individual layers and established interoperability in the Medical Device. The Continua Design Guidelines define a profile for discovery and pairing, user notification, quality of service, and simple secure pairing.
4.1.5 Bluetooth Low Energy Interface
The Bluetooth LE interface utilizes the Bluetooth LE protocol with data types compatible to the IEEE 11073-10101 nomenclature and the IEEE 11073-20601 domain information model. The Continua Design Guidelines defines further guidelines for device discovery, connection establishment, pairing, service discovery and bonding, user notification, authentication, device information requirements, date and time requirements,certification and regulatory aspects, and transcoding to ensure interoperability and appropriate security.
4.1.6 Security And Privacy
Data confidentiality and integrity across the Personal Health Device Interface is achieved via the underlying network communication technology associated with each device. For example, a PHD interface employing the Bluetooth LE transport would utilize LE security mechanisms such as Passkey Entry Pairing, association models, key generation, and encryption.
72 Ukraine: Rural Health and Telemedicine Standards
4.2 Services Interfaces
The Services Interface operates between the Local Integration Hub and the Integration Engine running in the Telemedicine Service. It covers the uploading of data/observations from Medical Devices, exchange of questionnaires and responses, consent management, capabilities exchange, and authenticated persistent sessions over a wide area network. The Continua Design Guidelines ensure interoperability by constraining specifications from IHE (Integrating the Healthcare Enterprise) and standards from HL7 (Health Level Seven) and providing implementation guidance and interface certification. IHE's PCD-01 transaction is used as the basis of this interface specification. It allows the use of common nomenclature, defined by the ISO/IEEE 11073 committee, for all devices across all interfaces. For further details, refer to: https://wiki.ihe.net/index.php/PCD_Technical_Framework The interface is defined in terms of • data payload • message exchange framework • security See the CDG H.812 “Services Interface Design Guidelines” for more information. These cover specifications for:
4.2.1 Data Payloads
• Mapping IEEE 11073-20601 Attributes • Observation Upload • Questionnaire • Consent Management • Capabilities Exchange • Authenticated Persistent Session
73 Ukraine: Rural Health and Telemedicine
4.2.2 Message Exchange Frameworks • SOAP & SAML • REST & OAuth FHIR • REST & OAuth hData • Capabilities Exchange
4.2.3 Security and Privacy • Consent Management • Consent Enforcement • Auditing • Confidentiality, Integrity, and Service Authentication • Entity Authentication
4.3 Healthcare Information System Interface The interface between the Integration Engine running in the Telemedicine Service and the MIS (also running at Regional or District level in the Virtual Data Centre), The Continua Design Guidelines establish the basic standards, rules and restrictions in the data, message, and transport protocols necessary to enable the transfer of pertinent information from the Integration Engine to the MIS. See the document CDG H.813 “Healthcare Information System Interface” for more information.
4.3.1 Data Payload The Continua Design Guidelines recommend the HL7 PHMR (Personal Health Medical Record) to facilitate the accurate transfer of both coded patient results from personal health devices and textual summary results . The PHMR implementation is based on the HL7 V3 architecture and is a derivative of the HL7 Clinical Document Architecture (CDA R2). As such, it is a structured XML based file that has specified clauses for various types of health information.
74 Ukraine: Rural Health and Telemedicine Standards
Placing the data derived from Services Interface messages (PCD-01 or FHIR) entails transforming the data to specific document elements in their proper format. Along with any desired data from other sources, this total set of information comprises a single PHMR document.
4.3.2 Message Exchange Framework The message exchange framework employs a number of IHE profiles The IHE Patient Identifier Cross-reference (PIX) profile provides a standards- based interface for managing identifiers across organizational and political domains ensuring that Medical Devices can correctly associate personal health data with the right patient. The IHE Cross-Enterprise Document Sharing (XDS) profile handles the exchange of patient information between providers via secure connection over the Private Healthcare Network, secure Email Service, or delivery on portable media (e.g. memory stick). The IHE Cross-Enterprise Document Reliable (XDR) interchange profile provides for explicit exchange of patient information between providers using a reliable point-to-point network communication. The IHE Cross-Enterprise Document Media (XDM) interchange profile employing ZIP and S-MIME was selected for secure indirect communication of pertinent patient information between caregivers. This type of data exchange is deprecated in the Telemedicine Service; all information should be passed on secure network connections and stored in the patient MIS.
4.3.3 Security & Privacy The recommendations for security and privacy cover the following: • Confidentiality, Integrity, and Service Authentication • Entity Authentication • Identity Management • Consent Management • Consent Enforcement • Non-Repudiation of Origin • Auditing
75 Ukraine: Rural Health and Telemedicine
5 INFRASTRUCTURE SPECIFICATIONS
The Telemedicine Service infrastructure covers the four levels of organisation: from local Ambulatory Centres and emergency vehicles, regional and district hospitals (at which server rooms house Virtual Data Centres that host the software for the Telemedicine Service) and national level networks and services.
Fibre Network Mobile National Network Privat Health Network
Virtual Data Email EMPI IE VDI Regional Centre PACS MIS Apps
District Virtual Data Centre IE VDI MIS EHR Apps
Local
The specification of infrastructure covers the underlying network communications, hardware and software that are prerequisite to any Telemedicine service: • Private Healthcare Network • Network connections and bandwidth • Healthcare professional email service • Communications between regional and district hospitals • Networking at regional and district hospitals • Server rooms at regional and district hospitals • Virtual data centre • Teleconsultation room • Communications from Ambulatory Centres
5.1 Private Healthcare Network
The Telemedicine Service must run over a Virtual Private Network (VPN). This can be implemented at national level, or more likely using a set of regional implementations connected through gateways to the national network.
76 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
5.2 Network Connections and Bandwidth
The type of connection required at each healthcare facility depends on the level of network traffic to/from the facility. The following connection options should be considered Broadband is used to mean any high-speed Internet access that is always on and faster than dial-up access over traditional analogue or ISDN PSTN services. Broadband services are typically low cost as they are delivered over telephone lines, with the exception of FTTP (Fibre to the Premises).
Type Max Speed Description
ADSL1 8Mbit/s ADSL stands for Asymmetric Digital Subscriber ADSL2+ 24Mbit/s Line and is the most commonly available type of broadband, delivered through the copper wires of a phone line. Cable 152Mbit/s Cable networks use fibre optic and coaxial cables to deliver fast broadband services - as well as TV and phone services - direct to premises. Typically, this is for home users only. FTTC 38Mbit/s or Fibre-to-the-cabinet broadband involves fibre 76Mbit/s optic cables run from the telephone exchange to street cabinets before using standard copper telephone wires to connect to premises. FTTP 1Gbit/s Fibre-to-the-premises broadband involves fibre optic cables running directly to the premises. It is faster than fibre-to-the-cabinet but currently only constitutes a minority of broadband connections.
Distance does not affect Ethernet services and services are typically symmetric – meaning the download speed is equal to the upload speed. Ethernet services are typically more expensive than Broadband and require the installation of dedicated cabling.
77 Ukraine: Rural Health and Telemedicine
Type Max Speed Description
10M 10Mbps Delivered over fibre optic cables or a number of Ethernet copper cables bundled together. Suitable for a small site that requires synchronous connectivity. Typically no longer cost effective when compared to broadband or 100Mbps Ethernet alternatives. 100M 100Mbit/s Delivered over fibre optic cables. Suitable Ethernet for medium sites that require synchronous connectivity. A 1Gbps service with a low committed data rate (CDR) may be a cost effective alternative and provide an option for future growth. 1G 1Gbit/s Delivered over fibre optic cables. Suitable for Ethernet large sites that require synchronous connectivity. Medium bandwidth connections for large sites and regional data centres. 10G 10Gbit/s Services with a bandwidth greater than 1Gbps. Ethernet High bandwidth connections to enterprise data centres and central services such as national Email server.
5.3 Healthcare Professional Email Service
A secure Email Service, reserved for healthcare professionals and approved at national or regional level is an essential requirement for the implementation of Telemedicine Services. The Email Service can be used for sharing patient identifiable and sensitive information; email, messaging, and sharing can be accessed by any organisation commissioned to deliver healthcare or related activities. Ideally, the Email Service should be available at national level as part of the eHealth strategy, but in the case that this is not available, such a service must be implemented at regional level, in order to support the Telemedicine Service.
78 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
The Email Service should be covered by an information standard that defines the minimum non-functional requirements for a secure email service, covering the storage and transmission of email, including where email is used for the sharing of patient identifiable data. The standard should include: • the information security of the Email Service • transfer of sensitive information over insecure email • access from the Internet or mobile devices • exchange of information outside the boundaries of the secure standard. The Email Service must run on email servers installed on the Private Healthcare Network. These servers can be hosted in the Virtual Data Centres at regional level, or at national level as part of the national eHealth infrastructure.
5.4 Communications Between Regional and District Hospitals The Regional and District Hospitals will host the Virtual Data Centres from which applications are served to the Telemedicine Services. As the backbone of the service they must be connected through high speed fibre connections that are suitable to carry the anticipated level of network loading. It is recommended to use similar network specifications to those used in the Health and Social Care Network (HSCN) for the NHS in England. This is the third generation of a national private network infrastructure, so represents considerable background and experience in the field. Technical specifications are available through: https://digital.nhs.uk/services/health-and-social-care-network. The key specification documents for the HSCN are: HSCN Operational Design Overview which describes the technical operating model for HSCN https://digital.nhs.uk/binaries/content/assets/legacy/pdf/5/n/hscn_ operational_design_overview_v3.0_external_for_publication.pdf HSCN Solution Overview which describes the technical infrastructure and HSCN services that support this.
79 Ukraine: Rural Health and Telemedicine https://digital.nhs.uk/binaries/content/assets/legacy/pdf/i/3/hscn_solution_ overview_v3.0_external_for_publication.pdf Depending on bandwidth requirements the connection may realised using Broadband or Ethernet.
5.5 Networking at Regional and District Hospitals The general network within district and regional hospitals should be run as a 100Mb/s Ethernet network with appropriate switches and routers to support the anticipated network traffic.
5.6 Data Centres at Regional and District Hospitals Data centres (server rooms) must be procured and configured with reference to the specifications and standards detailed in: ANSI/BICSI 002-2019. Data Center Design and Implementation Best Practices Other useful publications from BICSI are: BICSI 009-2019. Data Center Operations and Maintenance Best Practices BICSI Essentials of Data Center Projects, 1st Edition A good summary of the best practice in implementation of server rooms is provided in Lensu, V., 2013. Building Secure IT Server Room. Laurea University of Applied Sciences. Where possible, data centres should be resilient 'Class 4' facilities, which means that all major systems and components are provided with N+1 redundancy. “N+1 redundancy is a form of resilience that ensures system availability in the event of component failure. Components (N) have at least one independent backup component (+1).” [wikipedia]
80 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
This level of redundancy is costly to achieve and one recommended strategy to achieve it across a region is to operate two data centres (for example, one at the regional hospital, one at a district hospital or emergency response centre). The most important considerations for the data centre are: • Site Selection and Preparation • Electrical Systems • Network Infrastructure • Heat Rejection and Cooling System • Fire Suppression and Detection • Data Centre Monitoring • Data Centre Support Requirements
5.6.1 Site Selection and Preparation
Item Requirement Data Centre Primary data centre located in server room at Regional Location Hospital, at least 80km from secondary centre. Secondary data centre(s) at one or more District Hospitals. Server room should be located on ground floor (ideally) or basement. Electrical room A separate room (separate from the server room) should be used for electrical equipment such as switchboards, generator transfer switches, Unintertuptible Power Supply, batteries (for the UPS). The Electrical Room should be located as close as possible to the main building electrical room and generators. Server room (computer room) requirements
81 Ukraine: Rural Health and Telemedicine
Item Requirement Ceiling or roof Ideally the server room should be located on the ground floor of a multi-story building (so have a ceiling, rather than a roof) The roof/ceiling must be capable of supporting any roof- top equipment installed on it. There should be no roof top / ceiling openings. Roof drains must be kept away from the server room. Room ceiling At least 3.5m, to allow for raised floor and 3m clearance height Windows No external windows Walls Ideally walls should be constructed of brick; drywall boards must be sealed before painting. Walls should be painted with particulate-free, water- based epoxy paint, with a smooth finish. Doors Doors should be designed for maximum security (materials, hinges and fittings, minimal air gaps, etc) Physical security Physical security of the server rooms should have two levels of access restriction – for example, restricted access to the room and locked equipment cabinets. Door access should be to authorised staff only, using swipe card or key-pad access code. Video surveillance of the server room, including the access door(s) is recommended. Floor The floor should be of concrete, painted with particulate- free, water-based epoxy paint, with a smooth finish.
82 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
Item Requirement Raised floor The server room should have a raised floor, if the room height is sufficient. The minimum height of the raised floor should be 46cm. Main advantages are to carry power cables (separated from network cables in overhead cable trays) and to improve air flow for cooling. Supports for the floor should be placed directly on the concrete base (not on the painted floor). Ceiling-mounted Cables should not be laid on bare concrete. cable trays Cabling and cable pathways should be installed overhead, if ceiling height is sufficient. Cable trays must not be placed directly under light fittings, fire detection or fire suppression outlets. Separation of Power and telecommunications cabling should be cabling separated both vertically and horizontally. In rooms with a raised floor and ceiling mounted cable trays, power cables can be run under floor, telecommunications cables in the overhead trays. Twisted pair and fibre optic cables should be separated using dividers; if this is not possible, then fibre optic cable should be placed on top of twisted pair cabling.
83 Ukraine: Rural Health and Telemedicine
5.6.2 Electrical Systems
Item Requirement Requirements for Fault Tolerant, Class 4, Electrical System (adapted from ANSI/BICSI 002-2019) General Two or more power sources, N+1 or better power Description systems, multiple paths with redundant components Component Equal or greater than N+1 Redundancy System Required Redundancy Number of utility One or more sources, with two inputs sources Power sources to Two or more critical load UPS sources to Uninterruptible Power Supply – two or more critical load Maintain under With reduction to no worse than N+1 during maintenance load Recovery from Automatically, with reduction to no worse than N+1 after failures the failure and prior to recovery
Utility source Two independent utility providers or two independent supply pathways These should already be in place at the hospital location Main and Must be located in a secure mechanical room. step down Must have cooling systems to support heat load and transformers correct humidity levels for each unit. Must be maintained by a qualified technician to factory standards and be supportable by extended factory warranty.
84 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
Item Requirement Main power Must be maintained by a qualified technician to factory control panel and standards. PLC (Program Must be located in a secure mechanical room. Logic Control) Must have HVAC systems to support heat load and correct humidity levels for each unit. Must have surge suppression sufficient to prevent large surges from damaging panels and equipment supported by panel. PLC must have password security. PLC must have UPS support for power failure. Motor control All controls must have automatic restart after power panels failure. Must be maintained by a qualified technician to factory standards. Must be located in a secure mechanical room. Must have cooling systems to support heat load and correct humidity levels for each unit. Generator Should comply with local regulations for generators. (alternative Should already be installed at hospital location, but source) additional generator may be required. Capacity to run 'critical load' of all elements deemed to be essential or emergency.
85 Ukraine: Rural Health and Telemedicine
Item Requirement Generator Generator must be start tested and run for at least one management hour once a month. A full load test and switching test must be conducted at least yearly. Maintenance logs must be kept on all tests and reflect all maintenance performed. All maintenance must be performed by a qualified technician to factory specifications. Management must include remote alarm panel (enunciator panel). Automatic Automatic switching from primary source to alternative Transfer Switches source (generator) Uninterruptible Uninterruptible Power Supply (UPS) systems in the data Power Supply centre must be sized to meet current and future needs, with sufficient battery backup to allow for a controlled shutdown of primary servers. UPS systems must be designed, installed and maintained by authorized electricians and technicians and housed in a secure location. UPS systems follow manufacturer’s recommended maintenance schedule. UPS systems must have bypass capability to allow for periodic maintenance. Backup batteries Must follow manufacturer's recommendations for system to be of sufficient quality and capacity to ensure a long life thus limiting breaks in the battery strings. Must be located in secure area with proper ventilation as required, separated from the server room. Must be installed and maintained by authorized technicians. Must be approved for use in computer equipment UPS systems.
86 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
Item Requirement Sub-panels Must be sized to meet current and future needs. Must be located in the data centre to minimize power runs to desired equipment. Panel maps must be maintained to reflect their most current usage. Sub-panels must never be opened at the face plate by anyone other than qualified electricians. All materials must be at least three feet away from sub-panels. Remote Power Must be located to maximize ease of distribution to Panels equipment. Must comply with BS/IEC/EN 60439-1. Power Strips Power Strips Must be sized to meet the power requirements of the cabinet in which they are installed. Power receptacles for power strips must be installed by qualified electricians. Monitoring systems must be IP capable. Power cable The power pathways must maintain a minimum layout separation from data cable pathway in accordance with ANSI/TIA-469-B Standards and the relevant Design and Construction Standards for Telecommunication Systems. Equipment power cables should be the minimum required length and slack/strain management must be employed. Cables must be arraigned to minimize air flow disruptions.
87 Ukraine: Rural Health and Telemedicine
Item Requirement Grounding All data centre equipment must be grounded in systems compliance with state and local codes. Data centre equipment grounds must be independent of all other building grounds (such as lightning protection systems). All metal objects must be bonded to ground including cabinets, racks, PDUs, CRACs, cable pathway, and any raised floor systems. Ground resistance should be < 1 Ohm. Monitoring All electrical equipment must be monitored. system Monitoring systems must be IP capable. System must have a central monitoring console located in an area such as a NOC and be remotely accessible. System must be able to report alarms at the central and remote consoles by email and send recorded cell phone messages. Monitoring system must have analysis and reporting function. System must be able to retain log files of equipment performance and incident history.
Maintenance and All electrical system components should be regularly testing inspected. Main power switches, transformers, automatic transfer switches, and other major electrical system equipment must be maintained by qualified technicians per factory specifications and recommendations for service cycles.
88 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
5.6.3 Network Infrastructure The network (cabling) infrastructure is defined in ANSI/BICSI 002-2019 as consisting of the following components: • Entrance pathways – support outside plant and cabling of the Network Service Provider, from the property line to the Server Room • Entrance Rooms (ER) – area that houses the Network Service Provider's edge equipment terminating outside plant cable and optical switches • Main Distribution Area (MDA) – houses routers, core switches, firewall, load balancers, DNS and core SAN fabric switches • •Horizontal Distribution Area (HDA) – intermediate switching between MDA and EDA • Equipment Distribution Area (EDA) – cabinets and racks that house processing or storage systems hardware
Item Requirement Requirements for Class 4 Network Infrastructure(adapted from ANSI/BICSI 002-2019) Network Service Two separate providers with fibre connection to the Provider Internet backbone. 10Gb/s fibre connection to each provider. Entrance Support outside plant and cabling of the Network Service pathways Provider, from the property line to the Server Room Redundant and diverse multi-path, each path with multiple conduits from the property line to each Entrance Room. Entrance room Entrance Rooms (ER) – area that houses the Network Service Provider's edge equipment terminating outside plant cable and optical switches Two, to support multiple service providers, providing physical separation between redundant providers' edge equipment.
89 Ukraine: Rural Health and Telemedicine
Item Requirement Main distribution Main Distribution Area (MDA) – houses routers, core area switches, firewall, load balancers, DNS and core SAN fabric switches Two, to support redundant core equipment. Physical separation is required to minimize common modes of failure. Horizontal Horizontal distribution area (HDA) - Intermediate distribution area switching between MDA and EDA Redundant, physically separated areas, to support redundant switching equipment. Equipment Equipment Distribution Area (EDA) - Cabinets and racks Distribution Area that house processing or storage systems hardware (EDA) Redundant components in physically separated racks
Overhead cable The data room must have a system to support overhead trays delivery of data connections to the equipment cabinets. The data pathways must maintain a minimum separation from high voltage power and lighting in accordance with ANSI/TIA-469-B Standards (American National Standards Institute/Telecommunications Industry Association) and the relevant Design and Construction Standards for Telecommunication Systems. Fibre standards Fibre installation must use 50 micron OM3 Laser optimized fibre. All fibre installations must be labelled and comply with the [XXX] Labelling Standard. Copper Copper jumpers must be CAT6 with Booted RJ45 standards connectors. All copper data cables must be labelled and comply with the [XXX] Labelling Standard. Grounding All cabinets and cable delivery pathways must be grounded in compliance with the relevant Design and Construction Standards for Telecommunication Systems.
90 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
5.6.4 Heat Rejection and Cooling System
A Heat Rejection and Cooling System must be installed and it is recommended to install a fluid-based system with Class 4 resilience, as defined in ANSI/BICSI 002-2019. This must be implemented in harness with effective Air Flow Management, so that cooling is delivered properly to the IT Equipment.
Item Requirement Requirements for Class 4 Heat Rejection and Cooling System (adapted from ANSI/BICSI 002-2019) Component N+1 for all components within a redundant system and redundancy N+2 for all components not within a redundant system System For all systems whose combination of components redundancy cannot be fault tolerant through component redundancy System controls Redundant systems to ensure fault tolerance of colling systems Power feed Redundant systems should have power feeds from separate upstream electrical distribution. Redundant components should be fed in such a way that cooling capacity does not drop below N+! when any upstream electrical distribution is offline. Ability to maintain Without reducing cooling capacity below N+1 under load Ability to recover At system or component level, without reducing cooling from failures capacity below N+1
91 Ukraine: Rural Health and Telemedicine
Item Requirement Capacity of Capacity should be calculated using standard algorithms, server room air based on the total heat output by IT Equipment and conditioning lighting (assuming that there are no people occupying the server room.. Cooling and related equipment must be sized to account for: The size of the cooling load of all equipment. • The size of the cooling load of the building (lighting, power equipment, personnel, building envelope). • Over sizing to account for humidification effects. • Over sizing to account for redundancy should a unit fail. • Over sizing to account for appropriate future growth projections. All cooling equipment must be designed, installed, and maintained by qualified technicians that meet local and state codes. All cooling equipment must follow the vendor’s recommended maintenance schedule. Air filtration media should be installed at air intake points. Media should be replaced on a regular schedule based on the manufacturer recommended filter lifespan. Heat Rejection Fluid-based system is preferred. and Cooling System Availability 24/7, 365 days per year Humidity/ Humidity and temperature must be maintained at a level temperature that is compliant with the equipment installed on the data control centre floor. Humidity injection units must have separate drains and be fed by conditioned water.
92 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
Item Requirement Cooling towers Units must be maintained by qualified maintenance technicians following factory guidelines. Units must be in a secure mechanical yard. Units should be designed and installed to eliminate single point of failure. Tower restart after power failure must be automatic. Towers must have a redundant power source to allow time for a controlled shutdown of supported areas. Pump systems Units must be located in a secure mechanical room. Units should be designed and installed to eliminate single point of failure. Pumps must restart automatically after a power failure. Pumps must have an emergency power source to allow time for a controlled shutdown of supported areas. Pipe system Pipe must be constructed of high quality rust- and coolant-resistant material. Pipe loops must have valves in several locations that allow sections of the loop to be isolated without interruption to the rest of the loop. Pipe loops must have isolation valves for each air conditioning unit. Air delivery Cold air delivery must be managed such that the and return required amount of air can be delivered to any necessary management equipment location. Hot air return must be managed to extract air directly to air conditioning units without mixing with cold air delivery. System All infrastructure systems supporting machine space monitoring services must be monitored on a continual basis. Monitoring must be at a central location such as a Network Operations Centre. Monitoring system must support a master reporting console that can also be accessed remotely (including history logs) and must notify support staff of alarms at central and remote sites.
93 Ukraine: Rural Health and Telemedicine
5.6.5 Fire Suppression and Detection
It is recommended to use a Gaseous Fire Suppression system, with associated fire detection. Gaseous Fire Suppression systems operate by discharging a 'clean agent' in the fire zone, at sufficient concentration to extinguish the fire. The agent should be discharged within 10 – 30 seconds of the fire detection at sufficient concentration to extinguish the fire within 60 seconds. The discharge should be triggered by a combination of two detectors; if only one is activated then an alarm is raised; if both are activated then the clean agent is discharged automatically, unless overridden manually.
Item Requirement Location The server room must be separated from other areas of the building using fire-resistant rated construction, including fire doors. Flammable Flammable material (including back up tapes, batteries) material must not be stored in the server room. Fire suppression Gaseous Fire Suppression system, with associated fire system detection. The extinguishing concentration of gas shall be maintained long enough for the materials that have been heated by the fire to coll sufficiently so that the fire will not reignite. 85% of the design concentration should be maintained at the highest levsl of combustibles in the protected space for at least 10 minutes or a time period long enough for response by trained fire fighters. A Gaseous Fire Suppression system shall not be used within a server room that has external air intake for the air conditioning system.
94 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
Item Requirement Activation The agent should be discharged within 10 – 30 seconds of the fire detection at sufficient concentration to extinguish the fire within 60 seconds. Fire detection Automatic fire detection triggers release of the gas. system Two detectors are required, in order to reduce false activations. The discharge should be triggered by a combination of two detectors; if only one is activated then an alarm is raised; if both are activated then the clean agent is discharged automatically, unless overridden manually. Manual Fire A land-line telephone and fire extinguisher should be Extinguisher located at each exit and 'emergence station'. Fire alarm system The components of the Fire Alarm and Detection System are: • Primary power source • Secondary power source • Control panel • Detection and initiation systems • Notification devices A supervised fire alarm system should be used, so that it is continuously monitored. The fire alarm system may be integrated into the wider building alarm system.
95 Ukraine: Rural Health and Telemedicine
5.6.6 Data Centre Monitoring
It is essential that the operational data centre is monitored through resilient systems that do not rely on the main data centre Electrical Systems or IT Infrastructure. According to ANSI/BICSI 002-2019, the following critical events must be monitored: • Fire: 1st detector alert • Fire: 2nd detector alert (“Gas released into the room”) • Water within the room • Power outage • UPS in use • Generator in use • Power restored • Critical air-conditioning failure (“Call maintenance”) • Room temperature high • Critical UPS failure (“Call maintenance”) • Generator Emergency Power Off has been depressed. In addition, physical security must be monitored though the use of an entry control system and video surveillance.
5.6.7 Data Centre Support Requirements
From the outset, the data centre operations must be governed by • an Operating Procedures Manual, • a Disaster Recovery Plan, • and a Maintenance Plan. These must be developed during the implementation of the data centre with staff recruited and trained, and/or contractors appointed, as required to operate the data centre. It is recommended that a Preventative Maintenance philosophy is adopted in the development of the Maintenance Plan.
96 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
5.7 Virtual Data Centre
The Virtual Data Centre must run a virtual machine architecture that comprises compute, storage, and networking resources. The Data Centre is made up of the Hypervisor (software) that provisions the virtual machines and the Information Technology Equipment – the physical hardware (servers, storage, network devices) on which the Hypervisor runs.
5.7.1 Hypervisor A Hypervisor is computer software, firmware or hardware that creates and runs virtual machines. A computer on which a Hypervisor runs one or more virtual machines is called a host machine, and each virtual machine is called a guest machine. The Hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. The Hypervisor runs virtual machines to host the main Telemedicine services and applications: Email Service, EMPI, Integration Engine, PACS, MIS, and Telemedicine Applications, integrated with the MIS. The databases of these services and applications may also be configured to run on separate virtual machines. In addition, the Hypervisor runs the server for the Virtual Desktop Infrastructure, hosting virtual desktops running the Local Integration Hub and MIS client, which are served to the Workstations situated at the Point of Care. The Virtual Data Centre may run at a single location (e.g. the Regional Hospital) or be distributed across multiple locations (e.g. the Regional Hospital and one or more District Hospitals). The distributed option may be useful for larger regions, where support teams may be located at some District Hospitals, in order to provide support for the workstations deployed at the Point of Care. In this case, the Virtual Data Centre at the District Hospital can run the Virtual Desktop Infrastructure for the local Workstations and instances of the Integration Server, MIS and Telemedicine Applications. There are a number of commercial and open source candidate products available as Hypervisors:
97 Ukraine: Rural Health and Telemedicine
• VMware ESXi • Oracle VM Server for x86 • Microsoft Hyper-V • KVM (Kernel-Based Virtual Machine, open source) In addition to the Hypervisor, the Virtual Data Centre can be enabled as a full cloud computing platform, using products based on the open source OpenStack. An alternative is to use HPE Helion OpenStack, which runs OpenStack on 'bare metal' without a Hypervisor. The OpenStack project is a global collaboration of developers and cloud computing technologists producing the open standard cloud computing platform for both public and private clouds. A Hypervisor/Openstack or HPE Helion OpenStack platform is capable of running virtual machines for Windows or Linux, so is suitable for Microsoft server based products.
5.7.2 Information Technology Equipment
The Information Technology (IT) Equipment in the data centre should be selected and configured specifically to run the Hypervisor and Virtual Desktop Infrastructure. For this reason, the Hypervisor and IT Equipment should be purchased together, usually from a single vendor. The general configuration of the IT Equipment is shown in the Figure (adapted from Cisco). The base IT equipment required to run the data centre hypervisors are: • rack servers (Intel VT or AMD -V chipsets) • Network Attached Storage / Storage Area Network (NAS / SAN) • network switches • security appliance (firewall, VPN, etc) • network routers
98 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
Application Virtual Virtual Storage Compute Access Services Core/Agg. Peering Backbone Software Machine Access & SAN
App Subscriber «A» Application 1
Subscriber «B» Internet Application 1 App Subscriber «A» Application 2 WAN/ App IP-NGN
Subscriber «B» Application 2 Partners App
Emleaded 10 G Ethernet Services 10G FCoE ACE 4G FC 1G Ethernet FW VIM to vSwich Subscriber «B» Application 3 vSwitch to HW App to HW/VM Int. Compute Stack
Virtual Switches Hypervisors Rack Servers Storage Arrays Security Appliance Ethernet Switch WAN/Pe Router Gigabit Ethernet Switch
Item Requirement Rack servers With specialised hypervisor chipsets (Intel VT or AMD-V). Sizing of the servers – CPU, RAM should be made in collaboration with the hardware/hypervisor vendor, using their standard sizing tools, taking into account: • The required server sizes for Telemedicine Service applications and infrastructure • The number of users of the Virtual Desktop Infrastructure
99 Ukraine: Rural Health and Telemedicine
Item Requirement Hypervisors Type 1 (bare metal) hypervisor Purchased with the rack servers, as a package from a single vendor Virtual Desktop Integrated with the hypervisor (purchased as a package Infrastructure with the hypervisor, from a single vendor) to serve managed desktops to the Telemedicine Server end users (clinician users). Guest Operating Licensing for the guest operating system on each virtual System machine. (Also licensing of the software for the Telemedicine Service infrastructure and applications) Remote desktop Depending on the Virtual Desktop Infrastructure used, USB redirection ppecialist software may be required to allow use of the local USB ports (for example to connect Telemedicine equipment and devices). Hypervisor Specialised hypervisor backup, with backup at the backup hypervisor layer (not backing up at the guest operating system layer) Data Protection Dedicated backup appliance with integrated Hierarchical Appliance and Storage Management, if appropriate. media Capacity to implement the backup strategy of the data centre, in conjunction with the data mirroring (Data Replication Appliance) for immediate data recovery Specialist appliance is required to support virtual machines and should be specified in collaboration with the supplier of the rack server/hypervisor.
100 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
Item Requirement Data Replication Where a second data centre is available, data can be Appliance mirrored to that location. Only the server virtual servers need to be mirrored. The Virtual Desktop Infrastructure can be 'mirrored' by a machine pool pre-configured in the second location. Specialist appliance is required to support virtual machines and should be specified in collaboration with the supplier of the rack server/hypervisor. Network Specified and sized in collaboration with the rack server/ Attached Storage hypervisor supplier, using their standard sizing tools, (NAS) taking into account: • The required server sizes for Telemedicine Service applications and infrastructure • The number of users of the Virtual Desktop Infrastructure Note that specialist NAS configurations may be required to support the Virtual Desktop Infrastructure Storage Array As per NAS Network (SAN) SAN Switches Hardware switches to SAN Virtual switches Virtual switches as part of the hypervisor linked to physical switches Ethernet switches As required to support the configuration of servers, NAS, hypervisors and virtual switches. Security Hardware for appliance • firewall • Virtual Private Network (VPN) WAN / PE Router Wide Area Network (WAN) / Provider Edge (PE) router.
101 Ukraine: Rural Health and Telemedicine
5.8 Teleconsultation Room
The rooms used to host Telemedicine Encounters must be prepared and maintained with the objective of providing an effective and secure environment for the consultation. At Ambulatory Centres, the room is likely to be the same room as used for any patient-clinician encounter; at District and Regional Hospitals dedicated rooms must be assigned and equipped for Telemedicine. The Ontario Health Network has developed guidelines that should be considered for “Telemedicine Space Location and Preparation”. These guidelines cover: • Location • Size • Windows • Power connections • Signage • Noise, acoustics and sound considerations • Clock • Furniture • Room layout • Lighting • Physical security
5.9 Communications to/from Ambulatory Centres
Where available, Ambulatory Centres can make fibre network connections to the Private Healthcare Network, but more usually will use a mobile network connection.
102 Ukraine: Rural Health and Telemedicine Infrastructure Specifications
3G/4G LTE Antenna Base Station
Outside Inside
Data Integration Telemedicine Core Store Engine Applications MIS Router Local Integration Hub MIS Wired Ethernet Workstation
To boost the mobile network signal strength, a 3G / 4G LTE Antenna should be used, fixed to an external wall of the Ambulatory Centre. The cable from the antenna should be attached to a Router with built-in cellular connectivity (3G / 4G LTE), slot for a SIM card, ADSL/VDSL wired connectivity and the capability to serve a local area network to the Ambulatory Centre through wired (Ethernet) or wireless network. The Antenna / Router should deliver sufficient bandwidth to enable Telemedicine Services to operate effectively. The minimum bandwidth requirements for Teleconsultation are shown in the Table below (source: Polycom).
High Profile Bandwidth (Kbps) Baseline Resolution Resolution
256 4SIF (704 x 480) 4SIF (704 x 480) 384 4SIF (704 x 480) 4SIF (704 x 480) 512 720p (1280 x 720) 4SIF (704 x 480) 768 720p (1280 x 720) 4SIF (704 x 480) 1024 1080p (1920 x 1080) 720p (1280 x 720) 1472 1080p (1920 x 1080) 720p (1280 x 720) 1920 1080p (1920 x 1080) 1080p (1920 x 1080)
103 Ukraine: Rural Health and Telemedicine
Signal strength parameters can normally be measured by running a network diagnostic through the software of the Router. The parameters should be compared with the values shown below. (Source: www.dipolnet.com). RSRP (dBm) - (Reference Signal Receive Power) - measure of the signal strength. • more than -79 dBm - very good signal strength, • from -80 dBm to -90 dBm - good signal strength, • from -91 dBm to -100 dBm - poor signal strength. Need for an outdoor antenna or finding a better location of the modem • less than -100 dBm - very poor signal strength. It is necessary to use an outdoor antenna RSRQ (dB) - (Reference Signal Received Quality) - measure of the signal quality. • more than -9 dB - very good, • from -10 dB to -15 dB - good, • from -16 dB to -20 dB - bad. Need for an outdoor antenna or finding a better location of the modem • less than -20 dB - very bad It is necessary to use an outdoor antenna SINR (dB) - (Signal to Interference plus Noise Ratio) - measure of signal quality with respect to interference. • more than 21 dB - very good, • from 13 dB to 20 dB - good, • from 0 dB to 12 dB - bad. It is necessary to use an outdoor antenna • less than 0 dB - very bad. It is necessary to use an outdoor antenna RSSI - Received Signal Strength Indicator • more than -73 dBm - very good, • from -75 dBm to -85 dBm - good, • from -87 dBm to -93 dBm - bad. Need for an outdoor antenna or finding a better location of the router • less than -95 dBm - very bad. It is necessary to use an outdoor antenna
104 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6 PRODUCT CATALOGUE – HARDWARE
Categorisation of hardware products, with reference to the Technical Architecture, including high-level functional specification of each product type, standards requirements and criteria for evaluation of candidate products. Examples of products in each category may be provided here. Telemedicine Services should only be implemented using products that have been approved and listed in the Product Catalogue. The formal approval process is made for a specific product, in one or more Functional Profiles. It involves three steps: • install the product at an approved Telemedicine Sandbox • verify that the functional specification of the product meets the functional requirements listed in the Product Catalogue • verify that the product uses the open standards listed in the Product Catalogue The verification process involves a formal set of tests that ensure that the product, as installed and configured in the Telemedicine Sandbox, interoperates with the other components of the Functional Profile for which it is being considered. The first version of the Product Catalogue should contain example products which were already in use in Telemedicine Services in the country at the time this Handbook was published.
6.1 Category – Server Hardware for Virtual Data Centre
The servers for the Virtual Data Centre must be capable of running the chosen Hypervisor, including hardware support for virtualisation, where appropriate. The choice of Server Hardware and Hypervisor products should normally be made together and involve estimates of the number of virtual machines required. The specifications here are for rack servers to host Hypervisors and Virtual Desktop Infrastructure.
105 Ukraine: Rural Health and Telemedicine
Open Functional Specification Standards
To support VMs running Windows or more recent versions of Linux, an Intel VT or AMD-V 64-bit x86-based system with one or more CPU(s) is required. To support 64-bit virtual machines, support for hardware virtualisation (Intel VT-x or AMD RVI) must be enabled on x64 CPUs. Sizing of the servers – CPU, RAM should be made in collaboration with the hardware/hypervisor vendor, using their standard sizing tools, taking into account: The required server sizes for Telemedicine Service applications and infrastructure The number of users of the Virtual Desktop Infrastructure Example Products Rack server based on Intel Xeon E5-46xx/26xx/16xx v4 CPU, 128 Gb RAM Rack server based on AMD EPYC 7xx1 CPU, 128 Gb RAM
106 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.2 Category – Security Appliance for Virtual Data Centre
Specialised hardware appliance with integrated software for firewall, security protection and Virtual Private Network (VPN)
Open Functional Specification Standards
Rack mounted Redundant power supply Swappable hard drive Ethernet and fibre ports 10/100/1000, Mbps autonegotiate Firewall Virus detection Malware protection VPN management Example Products Proprietary, Cisco S690 www.cisco. com
107 Ukraine: Rural Health and Telemedicine
6.3 Category – WAN / PE Router for Virtual Data Centre
Wide Area Network / Provider Edge Router connects to the external (Internet) network service provider fibre end point.
Functional Specification Open Standards
Rack mounted Redundant power supply Gb Ethernet ports Two 10Gb Ethernet ports Software controlled Example Products Cisco ASR 1001 Proprietary, www.cisco.com
108 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.4 Category – Network Switches for Virtual Data Centre
Network switches, which may include specialist equipment to support Virtual Switches in the hypervisor.
Functional Specification Open Standards
Rack mounted Redundant power supply For example May be optimised for virtual switches in IEEE 802.3z, IEEE 802.1D, hypervisor environment IEEE 802.1Q, IEEE 802.1p, 10Gbps Ethernet IEEE 802.3x, IEEE 802.3ad 1Gbps ports (LACP), IEEE 802.1w, IEEE DHCP support 802.1x, IEEE 802.1s ARP support Example Products Cisco Catalyst 3850 Cisco, proprietary Cisco Nexus 1000V Cisco, proprietary
109 Ukraine: Rural Health and Telemedicine
6.5 Category – Storage Array for Virtual Data Centre
Network Attached Storage and/or Storage Area Network, optimised for use with the installed hypervisor.
Functional Specification Open Standards
Rack mounted Redundant power supply Fibre Channel iSCSI SAN Expandable storage Swappable disks Up to *for example) 300Tb capacity Example Products CyberStore 224S 12GB/s Storage Server Broadberry Dell EMC Unity XT Hybrid Unified Storage Dell
110 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.6 Category – Data Protection Appliance for Virtual Data Centre
Specialised hardware appliance with integrated software for back up of the virtual machine hypervisors.
Functional Specification Open Standards
Rack mounted Redundant power supply Designed for hypervisor backup Access/restore individual files on virtual machines Disaster recovery Malware recovery Long term data retention Example Products Dell EMC IDPA DP8300
6.7 Category – Data Replication Appliance for Virtual Data Centre
Specialised hardware appliance with integrated software for mirroring of the virtual machine hypervisors to a second, remote, data centre.
111 Ukraine: Rural Health and Telemedicine
6.7 Category – 3G / 4G LTE Antenna (for Rural Ambulatory Centre)
Functional Specification Open Standards
For 4G / 3G and 2G networks Gain between 3 and 6 dBi Omni Directional Weatherproof housing Mast or wall mounting Example Products Solwise Outdoor 3G/4G LTE 2dBi Cross Polarised Omni-Directional Antenna
WBS - 3G / 4G LTE Antenna (for Rural Ambulatory Centre)
Work Item Effort
Deliver and unpack Assemble antenna Fix external mount Run and fix cables Fix antenna to external mount Terminate cables and connect to router Test signal strength and router connection
112 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.8 Category – Router (for Rural Ambulatory Centre)
Functional Specification Open Standards
Dual-band (2.4/5Ghz) simultaneous wireless (300Mb/s + 1733Mb/s) Built-in 3G/4G LTE Cellular Connectivity. LTE Speed Up to 150/50 Mbs/s (RX/TX). Built-in standard SIM slot. Minimum 4-Port Gigabit LAN. WAN Connectivity through: ADSL/VDSL. 3G/4G/LTE (Internal SIM slot). 3G/4G/LTE (Optional USB Modem). Ethernet (RJ45). Send and receive text messages (SMS). Status reports by SMS (text message). Compatible with all main 3G/4G Providers in the country. Built-in 802.11ac Wireless Example Products
113 Ukraine: Rural Health and Telemedicine
6.9 Category – Desktop Computer (Telemedicine Workstation)
A personal computer (PC) which runs the remote desktop served by the Remote Desktop Infrastructure and makes connection with the local Telemedicine devices.
Functional Specification Open Standards
X86 processor RAM 8Gb sufficient Disk drive 200Gb sufficient Large Screen Monitor (HDMI) HDMI Keyboard Bluetooth Mouse (essential) Touch screen (optional) USB Bluetooth (inbuilt or plugin adaptor) Zigbee (inbuilt or plugin adaptor) USB Ports Ethernet port Example Products Any commodity PC is suitable
114 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.10 Category – Thin Client Computer (Telemedicine Workstation)
An alternative to using a personal computer (PC) for the Telemedicine Workstation, which has reduced specification and specialist operating system, boots directly to the remote desktop served by the Remote Desktop Infrastructure, and makes connection with the local Telemedicine devices.
Functional Specification Open Standards
X86 processor RAM 2Gb sufficient Flash storage (minimal) HDMI Large Screen Monitor (HDMI) Keyboard Bluetooth Mouse (essential) USB Touch screen (optional) Bluetooth (inbuilt or plugin adaptor) Ethernet Zigbee (inbuilt or plugin adaptor) USB Ports Example Products Wyse 3040 thin client Proprietary from Dell
115 Ukraine: Rural Health and Telemedicine
6.11 Category - USB to Bluetooth Adapter
USB connected device which enables Bluetooth connectivity for the workstation.
Functional Specification Open Standards
Compatible with workstation operating system Bluetooth Plug into standard USB port Support connection to multiple Bluetooth USB devices simultaneously. Wireless range up to 10m Support latest Bluetooth specifications Example Products Belkin F8T065BF USB 4.0 Bluetooth Adapter ASUS USB-BT400 Bluetooth 4.0 USB Adapter
116 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.12 Category - USB to Zigbee Adapter
Every ZigBee network must have one coordinator and can have lots of routers and end points. A USB to Zigbee adaptor runs the Zigbee coordinator and a Zigbee router through the USB port of a PC.
Functional Specification Open Standards
Zigbee®/Zigbee Pro 2007 wireless connectivity Zigbee Integrated 2.4GHz, IEEE 802.15.4-compliant USB coprocessor Antenna (according to range requirement) USB 2.0 interface Example Products ProBee USB to Zigbee Adapter
117 Ukraine: Rural Health and Telemedicine
6.14 Category – Video Conferencing Kit
Hardware to link video conference devices (microphone, video camera, video monitor, etc) with the video conferencing software (Teleconsultation Application).
Functional Specification Open Standards
Large screen monitor for visual USB connection to PC communications Camera (webcam) suitable for viewing Bluetooth participants and any patient signs/symptoms 1080p HD video (e.g. skin lesions, rashes wounds, etc) Microphone HDMI connection Speakers H.323, SIP: AES-128 Acoustic echo cancellation (Encryption) Noise reduction technology Media Encryption Example Products Logitech GROUP video conferencing kit Commercial kit (requires PC and large screen monitor) Polycom RealPresence Debut Videoconferencing System (requires large Commercial kit screen monitor)
118 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.15 Category – Multi-Lead ECG
Medical device which captures the electrical activity of the heart, including electrocardiographic data streaming and integration with the Telecardiology Application.
Functional Specification Open Standards
Multichannel (up to 12 lead) ST segment analysis MIS interface Internationally recognised Sampling rate Frequency response range USB Cables Filter for muscle tremor Monitoring display format QTc formula selection capability Example Products 12-Lead Digital ECG I AMD-3400
119 Ukraine: Rural Health and Telemedicine
6.16 Category – Digital Stethoscope
Medical device which detects sounds produced by the heart, including auscultated sound data streaming and integration with the Telecardiology Application.
Functional Specification Open Standards
Sound amplification Bluetooth Ambient Noise Reduction Frictional noise dampening Example Products 3M™ Littmann® Electronic Stethoscope Commercial Model 3200
120 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.17 Category – Pulse Oximeter
Medical device for measuring the proportion of oxygenated haemoglobin in the blood, including medical data streaming and integration with the Telemonitoring Application.
Functional Specification Open Standards
Modular & Suitable for Adult/Paediatric/ Patients monitoring SPO2 and PR display, PR waveform and bar USB graph display Synchronous display on the oximeter and Bluetooth computer Display SpO2 Range Display PR Range Rechargeable battery Example Products Wireless/Bluetooth Pulse Oximeter CMS50E with alarm
121 Ukraine: Rural Health and Telemedicine
6.18 Category – Digital Dermatoscope
Medical device which captures skin images/video, including data streaming and integration with the Telediagnosis Application.
Functional Specification Open Standards
HD Camera Sensor to stream or record images and video of the human body. USB connection to PC Interchangeable connections for Bluetooth multidisciplinary medical applications Touchscreen LCD Auto focus with manual focus override Internal rechargeable battery Charging cradle Example Products Avizia Horus Scope Multidisciplinary Telemedicine
122 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.19 Category – Digital Sphygmomanometer
Medical device which measures the blood pressure, including blood pressure data streaming and integration with the Telemonitoring Application.
Functional Specification Open Standards
Cuff pressure range 0 to 300 mmHg Systolic range 60 to 250 mmHg USB connection Diastolic range 30 to 160 mmHg 40 to 190 mmHg MIS integration Pulse rate range 35 to 199 bpm Pulse rate accuracy ±5.0% Overpressure cutoff 300 mmHg Example Products Welch Allyn Connex ProBP 3400
123 Ukraine: Rural Health and Telemedicine
6.20 Category – Digital Scale
Medical device for measuring body weight, including weight data streaming and integration with the Telemonitoring Application.
Functional Specification Open Standards
USB connection to PC Capacity 300 kg Increment 0.1 kg Weight and tare function
Example Products Tanita WB-800P plus Commercial
6.21 Category – Digital Spirometer
Medical device for measuring the volume of air inspired and expired by the lungs, including medical data streaming and integration with the Telemonitoring Application.
Functional Specification Open Standards
Spirometry tests: FVC, FEV1, FEV1/FVC, Attachment for Android PEF. based smartphones/tablets Volume accuracy: ± 3 % or 50 mL; Flow Integrated with BeeCardia accuracy: ± 5 % or 200 mL/s. Cloud Example Products BeeCardia Bee Spiro
124 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.22 Category – Digital Glucometer (Invasive)
Medical device which measures the concentration of glucose in the blood, including glucose data streaming and integration with the Telemonitoring Application.
Functional Specification Open Standards
Use small amount blood to measure BG level Lightweight portable USB Easy to read display Display result on screen Bluetooth Interface with the MIS Example Products Bayer Contour Next ACCU-CHEK AVIVA Plus
125 Ukraine: Rural Health and Telemedicine
6.23 Category – Digital Ophthalmoscope (Fundus Imaging)
Medical device for inspecting the retina and other parts of the eye, including the streaming of ophthalmoscopic data and integration with the Telescreening Application.
Functional Specification Open Standards
HD Camera Sensor to stream or record images and video of the human body. USB Interchangeable connections for multidisciplinary medical applications Bluetooth Touchscreen LCD Auto focus with manual focus override Internal rechargeable battery Charging cradle Example Products Avizia Horus Scope Multidisciplinary Telemedicine
126 Ukraine: Rural Health and Telemedicine Product Catalogue – Hardware
6.24 Category – Digital Image Capture System (Telepathology)
Image and video system which enables the retrieval of pathology data from Medical Devices or Applications, including integration with the Telediagnosis Application.
Functional Specification Open Standards
High resolution Attach to microscope or other equipment Integrated lighting system Example Products Meyer Instruments RTIS Proprietary, Meyer OlympusTelepathology Camera
127 Ukraine: Rural Health and Telemedicine
6.25 Category – Generic Wearable Devices
Smart electronic devices that can be worn on the body that allow for remote monitoring of different vital signs and health statistics.
Functional Specification Open Standards
Attach to body or clothing Long battery life Bluetooth Continuous sensors Detect vital signs Muscle movement Example Products BioStamp nPoint MC10, proprietary Hexoskin Smart Garments Hexoskin, proprietary
6.26 Category – Generic Sensors
Device which detects information about a patient including motion, flow, temperature, posture, gate, sounds, or smell. This is an emerging market – products should be investigated and procured on a trial basis, according to business and clinical requirements.
6.27 Category – Generic Body Fluids Analysis
Devices which perform measurement and analysis on body fluid samples that are not covered by a more specific equipment. This is an emerging market – products should be investigated and procured on a trial basis, according to business and clinical requirements.
128 Ukraine: Rural Health and Telemedicine Product Catalogue – Software
7 PRODUCT CATALOGUE – SOFTWARE
Categorisation of software products, with reference to the Technical Architecture, including high-level functional specification of each product type, standards requirements and criteria for evaluation of candidate products. Examples of products in each category may be provided here. Telemedicine Services should only be implemented using products that have been approved and listed in the Product Catalogue. The formal approval process is made for a specific product, in one or more Functional Profiles. It involves three steps: • install the product at an approved Telemedicine Service Sandbox • verify that the functional specification of the product meets the functional requirements listed in the Product Catalogue • verify that the product uses the open standards listed in the Product Catalogue The verification process involves a formal set of tests that ensure that the product, as installed and configured in the Sandbox, interoperates with the other components of the Functional Profile for which it is being considered. The first version of the Product Catalogue contains products which were already in use in Telemedicine Services in the country at the time this Handbook was published, or are free, open source software deployed in the Sandbox as examples (this software may or may not be in use in a live Telemedicine Service).
7.1 Category – Hypervisor
Bare-metal, type-1 hypervisor that can be directly installed on computer hardware without the need for a host operating system. A type-1 hypervisor controls, monitors and manages the hardware, peripheral and I/O resources directly.
129 Ukraine: Rural Health and Telemedicine
Functional Specification Open Standards
Type-1 (bare metal) Example Products Open source or supported Citrix Xen Server (licensed) Microsoft Hyper-V Commercial license VMWare ESX Commercial license
7.2 Category – Virtual Desktop Infrastructure Virtual Desktop Infrastructure implementations operate in a client/server computing environment. Application execution takes place on a remote operating system which communicates with the local client device over a network using a remote display protocol through which the user interacts with applications. All applications and data used remain on the remote system with only display, keyboard, and mouse information communicated with the local client device, which may be a conventional PC/laptop, a thin client device, a tablet, or a smartphone.
Functional Specification Open Standards
Client runs on Windows. Linux. Android, Ios Encrypted data connection Access to local drives and ports RDP (published, proprietary) Multiple users share same virtual desktop (during shared consultation) Example Products MS Remote Desktop Services / Remote Commercial, Microsoft Desktop Connection Xen Desktop / Xen Server Commercial, Citrix
130 Ukraine: Rural Health and Telemedicine Product Catalogue – Software
7.3 Category – Remote desktop USB redirection
Depending on the Virtual Desktop Infrastructure used, specialist software may be required to allow use of the local USB ports (for example to connect Telemedicine equipment and devices).
Functional Specification Open Standards
Access local USB port over RDP USB Configure as part of the VDI setup RDP Example Products USB Network Gate USB for Remote Desktop (FabulaTech) USB Redirector RDP Edition (Incentives Pro) Microsoft RemoteFX
7.4 Category – Directory Services
Directory services are software systems that store, organize and provide access to directory information in order to unify network resources. Directory services map the network names of network resources to network addresses and define a naming structure for networks. [Technopedia].
131 Ukraine: Rural Health and Telemedicine
Functional Specification Open Standards
Machine Authentication User Authentication User/System Groups Address book Organization Representation Asset Tracking LDAP Telephony Information Store User resource management E-mail address lookups Application Configuration store PBX Configuration store Example Products MS Active Directory Commercial - Microsoft OpenLDAP Open source
132 Ukraine: Rural Health and Telemedicine Product Catalogue – Software
7.5 Category – Email Server
Email servers generally feature two agents - Mail Delivery Agent (MDA) and Mail Transfer Agent (MTA) to deliver email from one point to another. The Mail Delivery Agent (MDA) is used to route the email from to its destination while the Mail Transfer Agent (MTA) transfers email between servers or computers using a client-server application architecture.
Functional Specification Open Standards
POP and IMAP Email support CardDAV, iCal and CalDAV Clients support POP & IMAP Email for Smartphones Mobile Web Client POP CardDAV Contacts & CalDAV Calendar Web Administration Console IMAP Command Line Interface (CLI) SMTP Integrated Anti-Spam and Anti-Virus Postscreen MTA Security CardDAV SSL SNI CalDAV Multi-Domain Support SSL Migration Tools Real-time Backup and Restore Disaster Recovery Hierarchical Storage Management (HSM) Example Products Zimbra – Email and Collaboration Suite Open source Java Apache Mail Enterprise Server Open source
133 Ukraine: Rural Health and Telemedicine
7.6 Category – Enterprise Master Patient Index (EMPI)
An Enterprise Master Patient Index or Enterprise-wide Master Patient index (EMPI) is a patient database used by healthcare organisations to maintain accurate medical data across its various departments. Patients are assigned a unique identifier, so they are represented only once across all the organisation's systems. [Wikipedia]
Functional Specification Open Standards
Open model for demographics Matching engine Resolve multiple identifiers REST API Extensible API Web services interface HL7 v2 Standard database HL7 FHIR Clustered database (scalability) Backup and recovery High transaction throughput Example Products Open source, free software OpenEMPI https://www.openempi.org
134 Ukraine: Rural Health and Telemedicine Product Catalogue – Software
7.7 Category – Integration Engine
Software which is used as a central hub between two or more systems which exchange information. Performs the tasks of routing messages (data) between the systems and of transforming data from one format (generated by the source system) to another (consumed by the target system)
Functional Specification Open Standards
HL7 V2
Connections using various protocols HL7 FHIR Message queuing DICOM Message routing XSLT Message cache TCP/MLLP Transformation ODBC (Database) Support standard healthcare message PDF and RTF documents protocols JMS High transaction throughput FTP/SFTP Standard database interfaces HTTP/HTTPS SMTP Example Products Open Source, Mozilla Public License (MPL) Mirth Connect https://svn.mirthcorp.com/ connect
135 Ukraine: Rural Health and Telemedicine
7.8 Category – Support Ticket System
Web-based system that handles various channels of User-Helpdesk interaction, including tracking and management of User requests, internal project tasks, and workflows.
Functional Specification Open Standards
Incoming tickets from email, web forms, and phone calls Route tickets to call handlers Auto-response to email and SMS tickets Workflow for call resolution Escalation to second and third line support teams Alerts/notifications Asset management/tracking Dashboard for call handling status/ statistics Customer portal to track call progress Example Products Mantis Bug Tracker Open source https://osticket.com osTicket Open source
136 Ukraine: Rural Health and Telemedicine Product Catalogue – Software
7.9 Category – Medical Information System (MIS)
A full longitudinal record of patient information which can be accessed by authorised users and used to import, input, view, schedule, order, prescribe and report.
Functional Specification Open Standards
Uniquely identify patients Store the full longitudinal patient record Merge, unmerge. archive records Import and export records Import events (compositions) to the patient record Search for patient, from demographics View events in the record Summary views and charts Clinical data entry ISO 13606 Alerts and notifications HL7 CDA Clinical correspondence Order communications FHIR Results reporting Scheduling Prescribing Role-based access control Care teams Care planning Care pathways Cross-patient cohort search Cross-patient reporting
Example Products
Open source medical practice OpenEMR management and health records. http://www.open-emr.org
Medical records system, targetted at OpenMRS developing countires. http://openmrs.org/
Archetype-based MIS, using ISO 13606 cityMIS and HL7 CDA http://cityMIS.org
137 Ukraine: Rural Health and Telemedicine
7.10 Category – Picture Archiving and Communications System (PACS)
Functional Specification Open Standards
Image storage Image retrieval Support all common modalities DICOM Structured reports (DICOM) HL7 v2 messaging Back up and recovery HL7 FHIR Integrated image viewer Collaboration workflow Example Products Open source, free GNU GPL ClearCanvas http://clearcanvas.github.io/ https://www.clearcanvas.ca
138 Ukraine: Rural Health and Telemedicine Product Catalogue – Software
7.11 Category – Teleconsultation Application
Functional Specification Open Standards
Scheduling of consultations Audio communication Video conferencing Consultation recording Screen sharing Collaborative document editing Chat and white boarding User and room management Support PC, tablet, mobile phone Web Services API for integration Example Products Open source, free software Apache OpenMeetings http://openmeetings. apache.org
139 Ukraine: Rural Health and Telemedicine
8 IMPLEMENTATION PROCEDURES
Any new Telemedicine Service must be planned, procured and implemented using international standards of best practice. Implementation projects should be based on a sound business case, with targeted benefits to patient outcomes. The recommended Implementation Methodology is the Unified Process, augmented with governance procedures from ISO 21500 and working practices for iterative development from the agile Scrum methodology. The planning process for a Project to implement a Telemedicine Service must start with a Vision Document that contains a clear expression of the scope of the project, the clinical need, the business case, the objectives and success criteria for the Project. From the Vision Document, a Terms of Reference for procurement of the service can be developed using the contents of the Vision Document with additional sections for the Work Breakdown Structure, Costing and Implementation Timescale (Project Plan).
8.1 Vision Document
The Vision Document is an artefact from the Unified Process that can be used to formalise the expectations from the Project of all stakeholders (from the Service Providers, Clinicians and Patients) prior to procurement and as a key input to the Terms of Reference for procurement. The Vision Document is prepared for a specific Service, which may be a Telemedicine Service as described by a Functional Profile or a component of the Telemedicine Infrastructure.
140 Ukraine: Rural Health and Telemedicine Implementation Procedures
Vision Document Descriptio Section
The introduction of the Vision document provides an overview of the entire document. It includes the purpose, Introduction scope, definitions, acronyms, abbreviations, references, and overview of this Vision document. Business opportunity - a statement of the opportunity to improve service delivery and/or clinical outcomes for patients. Problem Statement - a statement summarizing the problem Positioning being solved by this Project. Service Position Statement - an overall statement summarizing, at the highest level, the unique position the Service intends to fill in the overall provision of healthcare. A profile of the stakeholders and users involved in the project, Stakeholders and and the key problems that they perceive to be addressed Users by the proposed solution. These specific profiles should be created through interaction with the stakeholders themselves. Overview of the Service, with its use of the Infrastructure and Products. This should include: Service Perspective - how this service sits within the overall Telemedicine Service, including the infrastructure it requires, the organisational requirements and its relationship (if any) to other Services. For example, many Services will rely on, or incorporate, the basic Teleconsultation Service. Summary of Capabilities - a summary of the main benefits Service Overview brought to stakeholders and the Service features that will realise those benefits. Assumptions and dependencies - list each of the factors that affect the features stated in the Vision document. List assumptions that, if changed, will alter the Vision document. For example, an assumption may state that a specific operating system will be available for the hardware designated for the software product. If the operating system is not available, the Vision document will need to change.
141 Ukraine: Rural Health and Telemedicine
Functional requirements specification of the Service and all Infrastructure and Products required to deliver it. This is the detailed set of functional requirements for the Service and Service the Product features required. Each feature will be externally Specification perceivable by users, operators or other external systems. These features need to include a description of functionality and any relevant usability or system interface issues that must be addressed. Applicable Standards - International, open standards for software and hardware interfaces System requirements - these can include the supported host operating systems and network platforms, configurations, memory, peripherals, and companion software Performance requirements - Performance issues can Operational include such items as user load factors, bandwidth or Requirements communication capacity, throughput, accuracy, and reliability or response times under a variety of loading conditions. Environmental requirements - For hardware- based systems, environmental issues can include temperature, shock, humidity, radiation, and so forth. For software applications, environmental factors can include usage conditions, user environment, resource availability, maintenance issues, and error handling and recovery. Requirements for technical support of the operational service, maintenance of hardware and software products (including Support product support and maintenance from vendors, and any Requirements routine maintenance activities), training or technical staff and clinical users; documentation and online support resources.
Sections of the Vision Document can be generated from sections in this Implementation Handbook as follows:
142 Ukraine: Rural Health and Telemedicine Implementation Procedures
Vision Document Implementation Handbook Section
Functional Profile Summary and/or Introduction Infrastructure Category Summary Summaries from Technical Architecture, Infrastructure Positioning and Functional Profile(s)
Stakeholders and Stakeholder Summary and Users Functional Profile Summary Technical Architecture Organisation Service Overview Functional Profile Summary and/or Infrastructure Category Summary Functional Profile(s) Service Infrastructure Category Specification Product Catalogue Functional Profile(s)
Operational Infrastructure Category Requirements Product Catalogue Organisation and Operational Procedures Support Organisation and Operational Procedures Requirements
143 Ukraine: Rural Health and Telemedicine
8.2 Work Breakdown Structure (WBS) The Work Breakdown Structure (WBS) is a complete breakdown (can be a simple list, or a hierarchical decomposition) of everything that must be produced in order to deliver the project. Every item in the WBS is a physical product, as opposed to a task that needs to be performed in order to create the product. Products may include documents or other artefacts that are used in the project (design documents, specifications for configuration, test plans) but are primarily focused on the features of the Service finally delivered, as documented in the Service Specification. Hence the main input to production of the WBS is the Service Specification. which can itself be derived from sections in this Handbook. The granularity of the WBS (i.e. the level to which the overall physical product is broken down)is important to consider; each item in the WBS should take no more than 10 days to produce (ideally less than that) so some iteration may be required between the first version of the WBS and the final version which is produced after the Project Estimation has been concluded.
8.3 Project Estimation A reliable estimate of the resources (effort, time, cost) for a project can be made from the Work Breakdown Structure, provided the project is planned and controlled using the methodology outlined here, including the use of the agile Scrum methodology. For each item in the WBS an estimate must be produced of the number of days effort required, with the number of people involved and hence the duration of the overall task required to produce the item. The most reliable estimates are made by using some variation of the 'Wide Band Delphi' approach. Two or more implementers are asked to make independent estimates of the effort required to complete each work item and these are then combined to provide an overall estimate (and depending on the exact method used, a measure of the degree of confidence that can be placed in the estimate). Because of the constraints placed by the Scrum methodology, each item in the WBS must be sufficiently fine-grained to be completed within one sprint cycle. In practice, the aim should be for the effort for any work item to be less than 10 days.
144 Ukraine: Rural Health and Telemedicine Implementation Procedures
8.4 Project Costing
Using the Work Breakdown Structure and the standard Implementation Methodology, it is possible to create the estimate of total costs for the project. The full project cost is estimated from: • Cost estimates made on the WBS • Project management overhead of 10% • Contingency allowance of 20% • Capital cost of products (hardware and software) • Ongoing product costs (support and maintenance)
8.5 Timescales (Project Plan)
By using the Implementation Methodology defined in this Handbook, every implementation project follows the same generic plan, with a predictable timescale. The phases of the plan follow the four phases of the Unified Process and within each phase there are one or more sprint cycles. The number of cycles depends on the total effort estimates from the WBS, the resources.
8.6 Risk Register
The Risk Register should be maintained as a stand-alone document for the duration of the project, with a summary of the major risks also included in the Vision Document. It may also be decided to share part of the Risk Register in the Terms of Reference document, so that bidders can assess risks and be invited to identify any new risks which may be associated with their tender response.
8.7 Terms of Reference
The Terms of Reference is a document that expresses the information from the Vision Document in a form that is suitable for distribution to to the vendors invited to participate in the formal procurement of a Telemedicine Service.
145 Ukraine: Rural Health and Telemedicine
Telemedicine Vision Terms of Reference Handbook Document
Scope Derived from Vision Document. Positioning Derived from Vision Document. Stakeholders and Users Derived from Vision Document. Service Overview Derived from Vision Document. Service Specification Derived from Vision Document. Operational Requirements Derived from Vision Document.
146 Ukraine: Rural Health and Telemedicine Implementation Procedures
Telemedicine Vision Terms of Reference Handbook Document
Work Breakdown Structure Initial version is created from the Service Specification, expanded using the WBS included in the Handbook for each section in the Infrastructure, Functional Profiles and Product Catalogue. This is then refined though the process of Project Estimation. Costing As described in the Handbook, each item in the WBS is estimated and costed, a fixed project management overhead is added and a contingency applied to produce as overall cost proposal. The Terms of Reference includes the template to achieve this, with the actual figures filled out be the bidder as part of their cost proposal. The overall cost is then derived from the WBS costing and product costs (infrastructure, hardware and software) Timescales (project plan) For an implementation project run using the Scrum methodology, the timescale for delivery is determined by the number of sprints proposed and the length of the spring cycle. Support Requirements Derived from Vision Document.
147 Ukraine: Rural Health and Telemedicine
8.8 Project Governance – ISO 21500
ISO 21500 defines a project as “a unique set of processes consisting of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective. Achievement of the project objectives requires deliverables conforming to specific requirements, including multiple constraints such as time, cost and resources.” The following aspects of governance should be adopted from the guidance in ISO 21500 • Roles • Project Board • Business Case • Risk Register
8.9 Unified Process (of Software Engineering)
The Unified Process defines four phases of implementation: • Inception Specifies the vision of the Service and its business case. Defines the scope of the project. • Elaboration Planning of activities and resources, eliciting requirements, specifying the system features and designing the architecture, eliminating the highest identified risks • Construction Entire system is developed and tested, with user documentation • Transition Move the completed product to the user community, training them in its use and signing off acceptance Major milestones mark the boundaries between each phase
148 Ukraine: Rural Health and Telemedicine Implementation Procedures
• Lifecycle Objective Defined scope, estimated costs, understood requirements and risks • Lifecycle Architecture Detailed requirements, stable architecture, major risks resolved • Initial Operational Capability Functional system, full scope, release candidate • Product Release Service accepted, objectives satisfied, ready for live operation Studies made through analysis of large samples of projects run using the Unified Process have suggested the following benchmarks for the distribution of effort and elapsed time (schedule) in a typical project.
Phase Schedule Effort
Inception 10% 5% Elaboration 30% 20% Construction 50% 65% Transition 10% 10% Total 100% 100%
Phase Duration (weeks) Sprint Cycles
Inception 2 1 Elaboration 6 3 Construction 12 6 Transition 4 2 Total 24 12
149 Ukraine: Rural Health and Telemedicine
8.10 Scrum Methodology
Scrum is an agile development methodology which can be used to deliver a project of a controlled scope, to a defined level of quality, using a managed set of resources (usually people). Because of the way in which the methodology works, the timescale and cost of the project are directly determined by the resources used. At the outset, the final deliverable is planned to cover the full scope of the Service as defined on initiation, but because the deliverable is built iteratively, and quality is ensured during each iteration, it is usually possible to vary the scope of the final deliverable in order to ensure that the original timescale and budget are preserved. One strength of the Scrum methodology is that the Scope of the project is always expected to vary, since the set of requirements (functional specification) is reviewed with all stakeholders on each iteration of the project. In this way the stakeholders are able to agree, collectively, and iteratively, on variations in the scope of the final deliverable without resorting to more formal change control or contract variations. This approach is to flexible project scope is captured in the 'project triangle' as shown. The Scrum methodology consists of three main artefacts: • Product backlog • Sprint backlog • Burndown chart and three 'ceremonies': • Daily scrum meeting • Sprint planning meeting • Sprint review meeting The Work Breakdown Structure provides the first version of the Product Backlog - a complete breakdown of every item that will be produced in the project. At the start of each iterative cycle, called a 'sprint', some items are taken from the Product Backlog to form the Sprint Backlog - the set of items (features) that will be constructed during the sprint. The team then works on the items in the Sprint Backlog for the duration of the sprint. Each day, a stand-up meeting, called a Scrum, reviews the activities of each member of the team; the Scrum meeting should last no more than 15 minutes at the start of each day.
150 Ukraine: Rural Health and Telemedicine Implementation Procedures
At the end of the sprint, a Sprint Review meeting is held (for one hour) to assess whether the items in the Sprint Backlog have been completed, or not. A second (one hour) meeting, Sprint Planning, is also held at the end of each sprint to determine the Sprint Backlog for the next sprint.
151 Ukraine: Rural Health and Telemedicine
9 ORGANISATION AND OPERATIONAL PROCEDURES
The Operational Procedures of the Telemedicine Service define the working practices and governance of the service. The procedures cover: • Ownership, roles and responsibilities • Patient consent and data protection • Resourcing and scheduling of services • Record keeping • Guidelines for best clinical practice • Audit of the service • Technical support and maintenance The overall objective of the Telemedicine Service is to improve patient outcomes, within the constraints of resources, capabilities and expectations of stakeholders. The main 'actors' in the Telemedicine Service can be identified as the Organisation, the Technology and the Users (the clinical users of the Telemedicine Service). When these three are brought together effectively, then the target of improving patient outcomes can be achieved. The driving force that brings them together, and the glue that keeps them together, is Information. Organization: It is a main actor as it establishes the governance rules for the environment where the Telemedicine Service will be implemented. The organisation defines which types of Telemedicine encounter should be prioritized; such decisions encompass financial and strategic knowledge that is only available to this actor
152 Ukraine: Rural Health and Telemedicine Organisation and Operational Procedures
Organisation ec nolog
n or ation pro ed sers Patient Outco es
Technology: Is identified as the second main actor as it defines how the Telemedicine Service will interact with the environment in which it is implemented. The way in which the Technology fulfils the system requirements determines the usability of the service. This is a complex task, with the most importance, as it will determine how the system will support the existing work practices. It requires a close interaction with the Organization as it depends on its knowledge to be able to support care pathways. Users: Clinical users of the Telemedicine Services are identified as an actor in this context because it is they who will ultimately decide on which Telemedicine Services will be used in practice. This decision relates to their interaction with the Organization and the Technology. Users provide the knowledge required by the Organization to establish the above described prioritization. They are the main source of the knowledge necessary to define Telemedicine requirements. Mainly, Users are the most affected actor of eventual changes made in the organization to accommodate the new technology.
153 Ukraine: Rural Health and Telemedicine
Information: Information management, storage, distribution, and meaning is the reason why health care organizations aim for more Telemedicine. Information is what brings together the above described actors. Ultimately, it is how well this tasks are performed that will determine the success of Telemedicine Service implementations. In literature, two general workflows are mentioned. • The first is the pre-established workflow, defined as the workflow in an organisation, or at a specific organisational level (e.g. the cardiology ward in a hospital), before Telemedicine implementation. • The second is the new workflow, which describes the workflow after the implementation. Because of the impact of Telemedicine in the organization, and because of the consequent repercussions of these impacts back on the shape, use and functioning of Telemedicine, it is imperative to see and manage a Telemedicine Service implementation project as an organizational change process. Even better still, Telemedicine Service implementation should be conceived as organizational development, since that term implies that the technology is strategically intended to affect the Organization.
9.1 Barriers to Adoption
Despite the recognition of the enormous potential of Telemedicine to improve the health care sector, non-adoption rates as high as 75 % have been reported. Workflow related issues have been identified as major influencers of the outcome of Telemedicine Service implementations. This Handbook provides a strategy to address what have been reported as the most significant barriers to Telemedicine Service implementation. The six most reported barriers to the adoption of Telemedicine are as follows 1. Workload Increase in the amount of work and/or tasks (or time required to perform them) needed to complete a clinical process, when compared with the workflow established medicine implementation.
154 Ukraine: Rural Health and Telemedicine Organisation and Operational Procedures
Stresses the increase in the amount of work after medicine implementation. Telemedicine is described as being both time and resource intensive, and demonstrated discontent towards the amount of self-reported/recorded health data provided by the tool for assessment. 2. Workflow disruption Introducing Telemedicine Services into healthcare organisations triggers changes in the workflow. Such changes are not limited to the directly involved staff, but also have an impact on others within the organisation. Therefore, changes in the workflow have the potential to alter the organisation both in a negative or a positive way. Additionally, a change that reveals an initial positive development can lead to a rather negative outcome. Changes in the workflow are inevitable and necessary in order for the medicine implementation to be successful, the adoption of new medicine tools within the pre-established workflow creates problems during the implementation process. Workflow re-engineering to integrate medicine can be a trigger to improve: efficiency, distribution of tasks, patient safety, and the quality of the data collected from the patient 3. Alignment with clinical processes The Telemedicine Service does not integrate / support with the existing clinical process. Related to how supportive and well integrated the service is in the workflow 4. Undefined/changed roles The responsibility for a workflow task is not the same after the medical intervention, or new tasks were included in the workflow and no responsibilities were assigned. Clinicians may feel that they have a new role, tangential to their role as a healthcare professional, e.g. coaching patients in the use of the technology, analysing the self-reported data and subsequently answering the patient. Clinicians may need new competences and may need to take on new responsibilities, where these are required in the new workflow but have not been explicitly assigned.
155 Ukraine: Rural Health and Telemedicine
5. Undermining of face-to-face communication Impact on the personal contact with the patient and/or other healthcare professionals. Healthcare personnel evidences a preference for face-to-face communication over digital long-distance systems. The loss of contact between personnel is a trigger to the reduction of knowledge sharing and collegial relationships. Less mentioned, but still significant, are statements that medicine is impersonal and, therefore, undermines face-to-face communication, substantiated by the claim that the grounds of good nursing is physical presence, human touch, and use of all senses. 6. Staff turn-over Rotation of healthcare professionals between departments, or short term contracts, which require new learning / training on the Telemedicine tool. Need for continuous training of new staff.
9.2 Organisational Structure
The organisational structure is designed to avoid the most common cause for the non-adoption of Telemedicine Services. High level decision making and strategy is kept at the National level (to ensure that the Regions are as similar as possible in terms of Telemedicine Service availability and maturity), with each Region having an independent Telemedicine Service Organisation. The Local level (largest amount of users) is kept as simple as possible. supported directly from the Regional level or from the District level in larger regions.
156 Ukraine: Rural Health and Telemedicine Organisation and Operational Procedures
National Telemedicine Service Organisation
Chief Executive Officer
Chief Medical Officer Chief Information Officer
Clinical Team Technical Team
Telemedicine Service Organisation (Regional)
Chief Executive Officer
Chief Medical Officer Chief Information Officer
Clinical Team Technical Team
The organisational structure mirrors the three main actors identified above: organisation, user (clinical user of the Telemedicine Service) and technology. Both the National and Regional Service Organisations have a clinical team, headed by a Chief Medical Officer, and a technical team, headed by a Chief Information Officer. The distribution of the organisation, in terms of responsibilities, people and facilities is shown in the Figure below.
157 Ukraine: Rural Health and Telemedicine
National Telemedicine Service Organisation Ministry of Health Telemedicine Strategy Product Catalogue National Liaise with eHealth Strategy Ministry of Region Guidelines and Best Practice Telemedicine Sandbox team Procurement Support National Infrastructure Standards Management
Regional Hospital Telemedicine Service Organisation
Clinical Virtual Technical Workstations Experts Data Centre Team Regional Medical Devices System Training Users Team Training Facilities
Regional Hospital Telemedicine Service Team
Virtual Technical Workstations Data Centre Team District Medical Devices Support Training Team Team Training Facilities
Workstations Local Medical Devices Connectivity
9.2.1 National Telemedicine Service Organisation
National steering and coordination of Telemedicine Services through close cooperation with regional health authorities, district authorities, local authorities, technical organisations, and other interested parties. As the national competent authority for Telemedicine, the responsibilities include: • Implementation of the country's policy on Telemedicine; • Ensuring efficient national administration of Telemedicine, such as the administration and maintenance of the Product Catalogue; • Serving as the secretariat of national fora on Telemedicine; • Providing technical advice, including maintaining the Sandbox, and interpretation of the relevant laws; • Problem description and analysis in Telemedicine; • Formulating and following-up the national implementation plans in Telemedicine; • Liaising with the national eHealth programme • Establishing norms and standards;
158 Ukraine: Rural Health and Telemedicine Organisation and Operational Procedures
• Determining the codes, terminology and ICT standards, and their administration; • Development, introduction and administration of national Telemedicine services such as electronic patient's records.
9.2.2 Regional Telemedicine Service Organisation Regional steering and coordination of Telemedicine through close cooperation with district authorities, local authorities, technical organisations, and other interested parties. As the regional competent authority for Telemedicine, the responsibilities include: • Lead the public procurement of goods and services related to Telemedicine under the tutelage of the National Telemedicine Service Organization; • Clinicians training in medical devices and software related to medicine; • Education of technical staff in subjects related to medicine; • Maintain education facilities; • Host the Regional Telemedicine Service Support Group; • Provide support services to the Region; • Maintain the Telemedicine Service Support web portal; • Maintain the Telemedicine System(s), the Telemedicine Applications and Telemedicine Services.
9.2.3 District Telemedicine Service Team District steering and coordination of Telemedicine through close cooperation with local authorities, technical organisations, and other interested parties. The District Team is directed by the Telemedicine Service Organisation from the Regional level and the District team responsibilities include: • Host a Telemedicine Service Support person/team, that will serve as the Third Level of Support for the Regional Telemedicine Service Support Group; • Clinicians training in medical devices and software related to medicine; • Maintain education facilities; • Maintain the Telemedicine Applications, Systems and Services running at District or Local levels.
159 Ukraine: Rural Health and Telemedicine
9.2.4 Local Telemedicine Users
At the local level only Telemedicine Users are planned – these are the existing clinical staff, working at local level.
9.3 Support and Maintenance
No Telemedicine Service will operate effectively unless it includes robust procedures for support and maintenance of the infrastructure, hardware and software that underpin the service.
9.3.1 Actors
The following main actors are involved in the support service: • User Telemedicine Service User or a Telemedicine Application User • Contact Point A person in the Telemedicine Service Organization responsible for support services that receives the Ticket from the User. • Ticket Support request raised by a User, associated with a specific issue that requires resolution.
9.3.2 Levels of Support
There are four levels of support: • First Level of Support The Contact Point receives the Ticket and solves it or assigns it to the Second Level of support. • Second Level of Support A person, usually in the same group as the First Level of Support, to which a Ticket is assigned according to their specific expertise. which may be useful
160 Ukraine: Rural Health and Telemedicine Organisation and Operational Procedures
in resolving the issue presented in the Ticket. • Third Level of Support An expert person/group in the Telemedicine Service Team, to which a Ticket is assigned if the Second Level of Support does not have the expertise to solve. The Third Level are usually clinical or technical experts who have day-to-day duties beyond the provision of support, but who possess special skills or knowledge that may be required from time to time, to resolve a Ticket. • Fourth Level of Support A third party provider of the Telemedicine Service or Telemedicine Application, either internally or externally. Includes expert representatives of contracted product vendors.
9.3.3 Products
The Support Ticket System is (usually) a web-based system that handles various channels of User-Helpdesk interaction, including tracking and management of User requests, internal project tasks, and workflows.
9.3.4 Support Service Protocols 9.3.4.1 Scenario FAQ
• User acknowledges an issue in the Telemedicine Service or Telemedicine Application; • User opens the Telemedicine Service Support web portal; • User finds the question related to the identified issue on the list of FAQ; • User reviews responses; • User either accepts or rejects the suggested solution; • If the User identified issue is not solved, the User is forward to the Online Form within the Telemedicine Service Support Web Portal; • User answers the questions in the Online Form; • The most probable solution for the User identified issue is suggested to the User in the Telemedicine Service Support web portal;
161 Ukraine: Rural Health and Telemedicine
• User either accepts or rejects the suggested solution; • If the User identified issue is not solved, the User is offered the option of sending the description of the issue to a key email address (support@, sales@, helpdesk@, security@) within the Online Form; • The email, containing the User description of the issue and the answers provided in the Online Form, is received by the Ticketing System; • The Ticketing System creates a Ticket in the User’s name, notifies a Contact Point at the First Level of Support, and informs the User about Ticket; • Contact Point either rejects, accepts or raises the Ticket to the next Level of Support; • User Ticket is solved; • Ticket is closed in the Ticketing System.
9.3.4.2 Scenario Online forms • User acknowledges an issue in the Telemedicine Service or Telemedicine Application; • User opens the Telemedicine Service Support web portal; • User answers the questions in the Online Form; • The most probable solution for the User identified issue is suggested to the User in the Telemedicine Service Support web portal; • User either accepts or rejects the suggested solution; • If the User identified issue is not solved, the User is offered the option of sending the description of the issue to a key email address (support@, sales@, helpdesk@, security@) within the Online Form; • The email, containing the User description of the issue and the answers provided in the Online Form, is received by the Ticketing System; • The Ticketing System creates a Ticket in the User’s name, notifies a Contact Point at the First Level of Support, and informs the User about Ticket; • Contact Point either rejects, accepts or raises the Ticket to the next Level of Support; • User Ticket is solved; • Ticket is closed in the Ticketing System.
162 Ukraine: Rural Health and Telemedicine Organisation and Operational Procedures
9.3.4.3 Scenario Email • User acknowledges an issue in the Telemedicine Service or Telemedicine Application; • User sends a description of the issue to a key email address (support@, sales@, helpdesk@, security@) • The email, containing the User description of the issue, is received by the Ticketing System; • The Ticketing System creates a Ticket in the User’s name, notifies a Contact Point at the First Level of Support, and informs the User about Ticket; • Contact Point either rejects, accepts or raises the Ticket to the next Level of Support; • User Ticket is solved; • Ticket is closed in the Ticketing System.
9.3.4.4 Scenario Telephone For use when there is no network connection for online support. • User acknowledges the absence of data connection; • User calls the Telemedicine Support Line; • The Contact Point identifies the User and the reason for the contact; • The Contact Point creates/opens a Manual Ticket in the Ticketing System; • The Contact Point takes notes on the User described issue; • Contact Point either rejects or raises the Ticket to the next Level of Support; • User Ticket is solved; • Ticket is closed in the Ticketing System.
9.3.4.5 Scenario Chat (Using the Teleconsultation Service) • User acknowledges an issue in the Telemedicine Service or Telemedicine Application; • User starts a Chat session with the Telemedicine Service Organization; • The Contact Point identifies the User and the reason for the contact; • The Contact Point creates/opens a Manual Ticket in the Ticketing System;
163 Ukraine: Rural Health and Telemedicine
• The Contact Point takes notes on the User described issue; • Contact Point either rejects or raises the Ticket to the next Level of Support; • User Ticket is solved; • Ticket is closed in the Ticketing System.
9.4 Training and Education
Appropriate training of personnel increases the utilization of the Telemedicine Applications and Telemedicine Services, improves data collection capabilities, and improves confidence in clinical advice when relying on data collected through Telemedicine devices.
9.4.1 Clinician Training
Clinicians should be trained in the use of Medical Devices and software related to Telemedicine Focuses on the clinicians who will be using Telemedicine to do a clinical patient exam. Proper use of the medical devices is a key factor in the long-term success of Telemedicine Services. Solid training can overcome the lack of familiarity with new technologies, or an initial reluctance to rely on Telemedicine Services to make diagnosis and treatment decisions.
9.4.1.1 On-Site Training includes how to use Medical Devices properly and how these devices integrate with the Telemedicine Application and the MIS. Ideally, this should be an interactive training program emphasizing hands-on use of each medical device, introducing all aspects of medical device operations, maintenance, and troubleshooting.
9.4.1.2 Video Conference Video conference training, with the same content as the On-Site Training, held by the Region direct to the Training Facilities. Video conferencing training offers the side benefit of getting the trainee to use the technology as part of the training.
164 Ukraine: Rural Health and Telemedicine Evaluation Procedures
9.4.2 Technical Training
On-Site or Video Conference: Technical training focuses on assuring that technical staff has the knowledge to implement and support the Telemedicine Applications and Telemedicine Services as well as the clinicians.
9.4.3 Custom Training Programs
Training programs (both on-site and video conference) to meet the specific requirements of individual sites.
165 Ukraine: Rural Health and Telemedicine
10 EVALUATION PROCEDURES
Ongoing evaluation of Telemedicine services in live operation is an important factor in determining future investment decisions. Services should be evaluated against the original business case with a quantitative assessment of the effectiveness of the service, including the impact on patient outcomes. There are several issues to consider when designing a method for evaluation: • Efficiency (doing things right) is easier to measure than effectiveness (doing the right things) • New systems are often intended to change difficult-to-measure actions • Strategic systems elude measurement • Infrastructure investments cannot be cost justified on a Return On Investment (ROI) basis • It usually takes time for benefits to be identified
10.1 Information System (IS) Success Model
One of the most commonly used models to evaluate the success of information systems is the Information System (IS) Success Model developed by DeLone and McLean .This is an empirically tested and validated model. It is a comprehensive framework that allows users of the model to compare empirical research on information systems. The IS Success Model was originally published in 1992, based on 180 information system studies. It was based on communications research and empirical management information system research studies. The figure shows the updated DeLone and McLean IS Success Model.
10.2 Canada Health Infoway Benefits Evaluation Framework
The Canada Health Infoway Benefits Evaluation Framework supplemented the DeLone and McLean IS Success Model with information from a review by van
166 Ukraine: Rural Health and Telemedicine Evaluation Procedures
der Meijden on success of in-patient clinical information systems and a literature scan on evaluation studies of health information systems. Like the DeLone and McLean IS Success Model, the Framework allows evaluations to use a common framework and, if applicable, consistent measures and thus allows comparison of results.
Subcategories and Definitions of Dimension Category Measures Completeness, accuracy, relevance and Content Information comprehension. Quality Timeliness, reliability and consistency of Availability information when and where needed. Type of features and level of decision support Functionality (i.e. report or view, reference, reminder, alter, System assist and guide) Quality Accessibility (distance and availability), reliability Performance (up- and downtime) system response time. Security Type of security and access control features User training, ongoing technical support Service Responsiveness and availability of support, maintenance and Quality upgrades. Frequency, duration, location, type or nature Behaviour/pattern and flexibility of actual usage. Frequency, duration, location, type or nature Use Self-reported use and flexibility of perceived usage. Proportion of non-users and factors for non- Intention to use users to become users
167 Ukraine: Rural Health and Telemedicine
Subcategories and Definitions of Dimension Category Measures
Competency Knowledge, skills and experience
Perceived expectations, value, information/ User system/service quality and use of the system Satisfaction satisfaction (including clinician-patient interaction, preference, comfort and experience.
Ease of use User friendliness and learnability.
Patient safety: ··Preventable adverse events
Quality ··Surveillance - post marketing and public health (communicable disease surveillance) ··Reduction in patient risks and safety-related reportable drug and device events
Appropriateness and effectiveness: ··Adherence and compliance with benchmark, policy or practice standards and guidelines ··Self-reported practice or practice captured in the Net Benefits system ··Immunisation, testing and other relevant rates ··Continuity of care (1) information, relational and management continuity; (2) by individuals. multi- disciplinary teams or geographically dispersed teams; (3) access to information and effectiveness of general practitioner and specialist referral
Patient outcomes: ··Clinical outcomes ··Change in health status attributable to Telemedicine intervention
168 Ukraine: Rural Health and Telemedicine Evaluation Procedures
Subcategories and Definitions of Dimension Category Measures Ability of patients and clinicians to access services ··Availability, diversity and consolidation of services ··Timeliness, geographic, financial and cultural/ Access linguistic - removal of inequitable barriers (including affordability, acceptability and accommodation) Patient and clinician participation, patient self-management and access to his/her information. Efficiency: ··Provider resource use ··Short term improvement in outputs vs inputs and longer term in care continuity ··Improved health system management capability ··Improved patient efficiency (e.g. more efficient scheduling of pre-operative testing) Productivity ··Non-monetary effects Care coordination: ··Care provision by team ··Continuity of care across continuum Net cost: ··Monetary avoidance ··Monetary reductions, savings
169 Ukraine: Rural Health and Telemedicine
10.3 Proposed Evaluation Framework
For Telemedicine, it is recommended that evaluation studies be made to measure the following criteria: Individual Structure • patient, e.g. access to services, acceptability • provider, e.g. ♦♦ training to use the equipment ♦♦ change in practice Organizational Structure • scheduling • equipment location suitability • culture • cost • equipment effectiveness Process of Care, e.g. • satisfaction with care process • effectiveness of interaction compared to face-to-face • management of care process (care provider and patient) Individual Outcomes • Patient, e.g. ♦♦ satisfaction with outcome of care ♦♦ quality of life ♦♦ functional status • Clinician, e.g. ♦♦ satisfaction with outcome of care; ♦♦ number of re-admissions, ♦♦ frequency of adverse effects Organizational Outcomes, e.g. • efficient use of resources • cost effectiveness • utilization of services
170 Ukraine: Rural Health and Telemedicine Case Studies
11 CASE STUDIES
The case studies described in this section provide examples of successful implementations of Telemedicine Services that have been deployed in accordance with the guidance in this Handbook, and that can serve as templates for deployment of new services across the country.
171 Ukraine: Rural Health and Telemedicine
12 BIBLIOGRAPHY
Introduction to the Continua Design Guidelines https://www.pchalliance.org/ continua-design-guidelines CDG IH.811 “Personal Health Devices Interface Design Guidelines” CDG H.812 “Services Interface Design Guidelines” CDG H.813 “Healthcare Information System Interface” IHE PCD Technical Framework https://wiki.ihe.net/index.php/ PCD_Technical_Framework NHS Health and Social Care Network https://digital.nhs.uk/services/ health-and-social-care-network ANSI/BICSI 002-2019. Data Center Design and Implementation Best Practices BICSI 009-2019. Data Center Operations and Maintenance Best Practices BICSI Essentials of Data Center Projects, 1st Edition Lensu, V., 2013. Building Secure IT Server Room. Laurea University of Applied Sciences. Ontario Health Network. Telemedicine Space Location and Preparation DeLone, W.H. and McLean, E.R., 1992. Information systems success: The quest for the dependent variable. Information systems research, 3(1), pp.60-95.
172 Ukraine: Rural Health and Telemedicine Glossary
13 GLOSSARY
Term Definition
Any primary healthcare facility, including Primary Health Care Centre, a Medical Ambulatory Centre Outpatient Centre or a Feldsher-Midwife Station Telemedicine where patient data are stored at a remote location and transferred to the Telemedicine Service at a later date Asynchronous Telemedicine (also known as Store and Forward). Does not require a real-time connection between the Point of Care and the Telemedicine Service. A health care professional who works as a primary care giver of a patient in a Clinician hospital, skilled nursing facility, clinic, or patient's home. [Wikipedia] A full longitudinal record of patient information which can be accessed by Electronic Health Record authorised users and used to import, (EHR) input, view, schedule, order, prescribe and report. A clinician (usually a specialist) working remotely from the point of care who Expert Clinician provides advice to the PoC Clinician through the Telemedicine Encounter.
173 Term Definition
A description of a specific type of Telemedicine Encounter, defined by a Functional Profile workflow (Use Case), the Medical Devices, and Applications required to deliver it. A certified doctor who usually acts as the first point of contact with healthcare services for patients with acute or General Practitioner (GP) chronic conditions, as well as providing preventative care and health education services to the local population. Computer software, firmware or hardware that creates and runs virtual machines. A computer on which a Hypervisor runs one or more virtual machines is called a host machine, and each virtual machine Hypervisor is called a guest machine. The Hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Describe specific solutions to integration problems. A profile documents how standards will be used by the actions of each integrated system, to cooperate to address the problem. Referencing IHE Profiles IHE Integration and Content Profiles lets implementers and users be sure they’re talking about the same solution without having to restate the many technical details that ensure actual interoperability. See https://wiki.ihe.net/index.php/Profiles A recognised method for implementing an Implementation Methodology Information Technology project. Term Definition
Software which is used as a central hub between two or more systems which exchange information. Performs the tasks of routing messages (data) between the Integration Engine systems and of transforming data from one format (generated by the source system) to another (consumed by the target system) An international standard for project ISO 21500 management and governance. A piece of equipment (hardware) use to collect or generate clinical information about a patient. At the Point of Care Medical Device these may be devices which monitor or measure patient data, either invasively or non-invasively. The organisation (enterprise) responsible for co-ordinating the activities of the Telemedicine Service Organisations National Telemedicine Service across all regions. Its main responsibilities Organisation are to enable the national-level eHealth infrastructure required for Telemedicine, organise the Telemedicine Sandbox, maintain the Product Catalogue A relative, friend or other non-professional person authorised by the patient to assist Non-professional carer them in receiving care or advice through the Telemedicine service A person who is the subject of care or advice provided through the Telemedicine Patient service - must be registered with a General Practitioner. Term Definition
Technology which provides efficient Picture Archiving and storage and access to medical images Communications System made through different modalities (source (PACS) imaging equipment). The physical location in the Telemedicine Encounter at which patient care is delivered. If the Patient is involved in the encounter then their physical location is, by definition, the Point of Care. If the patient is not directly involved in Point of Care the encounter then the Point of Care is the location of the clinician who will be delivering care to the patient and who is seeking the advice or assistance of the Expert Clinician located at the Remote Care Provider. The GP, Feldsher, Midwife, Paramedic or Point of Care Clinician (PoC other care professional, working at the Clinician) Point of Care, who provides care or advice to the patient. A verified directory of products that are suitable for procurement as part of a Telemedicine Service in Ukraine. To be Product Catalogue listed in the catalogue, products should undergo verification for functional and standards compliance and be tested in the Telemedicine Sandbox. The physical location (usually a healthcare provider such as a Regional Hospital Remote Care Provider or District Hospital) at which the Expert Clinician is providing advice or assistance as part of the Telemedicine Encounter. Term Definition
The healthcare facility or service (usually a District Hospital, Regional Hospital or Remote Care Provider Specialist Healthcare Service) at which the Expert Clinician is located. A basic health clinic, in a rural location, with facilities for consultation, prescribing/ administration of drugs and non-specialist Rural Health Clinic treatment of acute or chronic conditions. Known as a Feldsher-Midwife Station in Ukraine. A certified healthcare professional who practices medicine in a rural location, under Rural Nurse Practitioner the direct or indirect supervision of a General Practitioner. Known as a Feldscher in Ukraine. Scrum An agile software development methodology. A Telemedicine Encounter in which patient data is passed continuously, in real time, Synchronous Telemedicine from the Point of Care to the Remote Care Provider. The overall architecture for the technical Technical Architecture implementation of Telemedicine in Ukraine. Delivery of healthcare by a Clinician interacting with the Patient at the Point of Telemedicine Care and an Expert Clinician working at a Remote Care Provider. A clinical consultation between a patient and/or carer and an Expert Clinician at a Telemedicine Encounter remote location, involving the transmission of clinical data from the Point of Care to the Remote Care Provider. Term Definition
A reference implementation of the Technical Architecture in which component Telemedicine Sandbox may be replaced by any candidate product for the purposes of testing and verification for admission to the Product Catalogue. The realisation of Telemedicine across a region for a specific Functional Profile, Telemedicine Service using the architecture, infrastructure and organisation described in this Handbook. The organisation (enterprise) responsible Telemedicine Service for commissioning and operating Organisation Telemedicine Services in a region. A patient or non-professional carer who is Telemedicine Service User provided with care or advice through the Telemedicine Service A clinician, patient or non-professional Telemedicine Application User carer who has access to use the hardware or software of the Telemedicine Service A four-phase software development Unified Process methodology. The following terms used in Ukraine, in place of the general terms defined in the Glossary.
Term Definition Feldscher Rural Nurse Practitioner. Feldsher-Midwife Station Rural Health Clinic Electronic Health Record (MIS). The MIS covers practice management, Medical Information System administration and health records, running (MIS) across primary and secondary care (Ambulatory Centres, District Hospitals, Regional Hospitals)