Suplemented Version of IHIS Specifications PDF

Ministry of Health of the Republic of Macedonia Health Sector Management Project Project Coordination Unit
TECHNICAL AND FUNCTIONAL REQUIREMENTS FOR INTEGRATED HEALTH INFORMATION SYSTEM OF THE REPUBLIC OF MACEDONIA (IHIS)
ICT REPORT (Contract activity C)
Final 1.2
November 2007
IHIS Specification
Version 1.2
Document status
Document purpose: To present technical specifications for Integrated Health Information System in the Republic of Macedonia Content: See table of Contents Document sign.: Report No.2 and No.3 (joint specifications of contract activity b and c) Status: Final Version: 1.2 Version Date: 13.11.2007 Client / User: MOH, PCU Authors / Prepared by: IPMIT d.o.o. Date of Delivery: 14.11.2007 WG, MoH Version History:
Version 0.1 Draft 0.2 Draft 0.3 Draft 0.4 Draft
Last Change 12.09.2007 14.09.2007 25.09.2007 01.10.2007 05.10.2007
Comments First draft on document structure First draft (structure & basic content) Second draft Harmonizing specifications with WG Sent to WG and MoH Final version for WG and WB verification Sent to WG for final verification Accepted comments from WG FINAL VERSION Accepted comments from WB
1.0 Final
15.10.2007 19.10.2007
1.1 Final 1.2 Final
27.10.2007 14.11.2007
Confidentiality: According to PCU and project procedures
Document copyright 2007 Ministry of Health, Republic of Macedonia, Skopje; All Rights Reserved. Reproduction of this document in part or in full in any manner and in any medium without the written consent of the author is unlawful. Limitations shall not apply to state authorities of the Republic of Macedonia. Violators will be prosecuted pursuant to the Copyright and Related Rights Act and the Penal Code of the Republic of Macedonia.
2007 Ministry of health
IHIS Specification
Version 1.2
Table of contents
1 PROJECT BACKGROUND ..........................................................................................6 1.1 1.2 2 Background information ......................................................................................6 Document purpose ...............................................................................................6
PROJECT DESCRIPTION............................................................................................7 2.1 2.2 2.3 2.4 2.5 Subject of the project ...........................................................................................7 Project scope ........................................................................................................8 Project objectives .................................................................................................8 Organization..........................................................................................................9 Processes............................................................................................................11
CURRENT STATE OF HEALTH IS IN THE REPUBLIC OF MACEDONIA ...............12 3.1 3.2 3.3 3.4 Introduction.........................................................................................................12 Key findings ........................................................................................................12 Current state in Health related institutions in Macedonia...............................13 Starting point for future IHIS..............................................................................14
FUTURE IHIS SPECIFICATIONS...............................................................................15 4.1 4.2 4.3 Future IHIS architecture .....................................................................................15 General IHIS use case and process description ..............................................16 Health Data & Application Center HDAC .......................................................17 Introduction of HDAC .....................................................................................17 Hardware........................................................................................................17 System Software, servers software and licenses ...........................................18 Central IHIS software, database and interfaces .............................................19 Common Health and other registers, coding tables .......................................20 Standards.......................................................................................................21 Security and User rights management ...........................................................22 User activity tracking User & activity LOG files ...........................................22 Telecommunications ......................................................................................23 System backup & Disaster recovery ...........................................................23 Data Migration.............................................................................................23 HDAC organization .....................................................................................24
3
4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 4.3.9 4.3.10 4.3.11 4.3.12
IHIS Specification
Version 1.2
4.4
Patient Health ID & Insurance card, Professional ID Health Card ..................24 Health insurance card and patient identification.............................................24 Professional staff identification.......................................................................25
4.4.1 4.4.2 4.5
HCI subsystem....................................................................................................25 Introduction of HCIs subsystem .....................................................................25 Hardware, System software and telecommunication for HCIs .......................26 Special medical/hospital software ..................................................................29 Financial, accountancy and administrative solution FAAS ..........................32 Database........................................................................................................34 User interface requirements ...........................................................................35
4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.6
Pharmacy subsystem.........................................................................................36 Introduction of Pharmacy requirements .........................................................36 Hardware, System Software and licenses, Telecommunication.....................36 Software solution for Pharmacies & Interfaces...............................................36
4.6.1 4.6.2 4.6.3 4.7
HIF subsystem ....................................................................................................37 Introduction of HIF requirements....................................................................37 Hardware, System Software and licenses, Telecommunication.....................37 Interfaces for HDAC HIF communication ....................................................37
4.7.1 4.7.2 4.7.3 4.8
(N)IHP subsystem ...............................................................................................40 Introduction of (N)IHP requirements...............................................................40 Hardware, System Software and licenses, Telecommunication.....................41 Software solution for (N)IHP...........................................................................42
4.8.1 4.8.2 4.8.3 4.9 4.10
Management subsystem ....................................................................................43 eHealth portal ..................................................................................................44 eHealth portal introduction ..........................................................................44 Portal functionality.......................................................................................44
4.10.1 4.10.2
5 TESTING, TRAINING, PRODUCTION, MAINTENANCE, Documentation, USER SUPPORT .........................................................................................................................45 5.1 5.2 5.3 Testing requirements .........................................................................................45 Training requirements........................................................................................46 Maintenance requirements and user support ..................................................46
IHIS Specification
Version 1.2
5.4 6 7 8
Documentation....................................................................................................49
IHIS & HDAC COMPLEXITY MEASURES.................................................................50 SCALABILITY, FUTURE IHIS UPGRADES...............................................................51 PROJECT IMPLEMENTATION PLAN .......................................................................51 8.1 Implementation phases, deliverables and time schedule (delivery plan) ......51
9 10
SELECTION CRITERIA - QUALIFICATIONS, MEASURES ......................................54 Documents and sources .......................................................................................57
Acronyms
IHIS Integrated Health Information System RMK Republic of Macedonia MoH Ministry of Health HDAC Health Data and Application Center HIF Health Insurance Fund HCI HealthCare Institution(s) Hospital, Health Centre(Home) WG Working Group NIHP National Institute for Health Protection IHP Institute for Health Protection (regional units) WHO World Health Organization EHR Electronic Health Record EPR Electronic Patient Record UCCS University Clinical Centre in Skopje
IHIS Specification
Version 1.2
1 PROJECT BACKGROUND
1.1 Background information
The Republic of Macedonia has received a Specific Investment Loan from the International Bank for Reconstruction and Development in amount of US $ 10 million toward the cost of a Health Sector Management Project. The project comprises of four components [1]: Component 1: Policy Formulation and Implementation Component 2: Strengthening HIF Governance and Management Component 3: Improving Service Delivery Component 4: Project Management, Monitoring and Evaluation The Macedonian health care system faces multiple challenges of improving access, quality and efficiency. The Government of Macedonias objectives are to obtain a healthcare system based on long term stability, sound governance and an appropriate institutional capacity in the key players in the health care system. It wants to see MOH, HIF and the health care providers operating in a reformed health care environment, all focused on the patient as the most important element in the health care system [1]. Within the Health Sector Management Project, there has been also developed Integrated Information System Strategy. Its primary aim is to recommend the necessary actions to rectify present deficiencies in health information systems and to put in place the frameworks to ensure the optimal development and utilization of health information [2].
1.2 Document purpose

This document represents functional and technical specifications for Integrated Health Information System of the Republic of Macedonia (also IHIS). Specifications are aligned with: Integrated Information System Strategy, current state of the health information system in Macedonia, concrete functional and information needs in the health sector recognized through several analyses in the past, modern trends in information technology field. The purpose of the document (specifications) is to present functional and technical requirements of IHIS to bidders and is therefore the basis for preparing their bids. Specifications include: 1. Project information 2. Current state of health information system in the Republic of Macedonia 3. Future IHIS architecture 4. Functional requirements 5. Technical requirements (system software, hardware, telecommunications, interfaces) 6. Other conditions regarding implementation, operating and maintenance of future IHIS
IHIS Specification
Version 1.2
7. Project plan and implementation phases 8. Other information important about the project and IHIS implementation for bidders
2 PROJECT DESCRIPTION
2.1 Subject of the project
Implementation, maintenance and user support of central Integrated Health information system (also IHIS) of the Republic of Macedonia, which will have to integrate all relevant health related institutions, public and private, including: Ministry of health, Health care institutions (Health homes, Hospitals), Pharmacies, Health insurance Fund, National Institute of Health Protection and regional units. It is decided that IHIS will be centralized information system with central EHR database and central software installed for all health care institutions. The majority of users will use the software solution through web browsers. No local servers or databases are planned except for Health insurance fund and Pharmacies which already have their own solution and therefore only integration is needed with IHIS. It is planned to establish one powerful Health Data & Application Center (also HDAC) for IHIS in Macedonia. Selected provider will have to offer software solution and also hardware and telecommunication equipment for Health Data & Application Center. It is also planned to provide bar code cards for patients and professionals for identification and authorization within health care related processes. The ministry is looking for provider to implement most adequate solution according to current situation and actual requirements. The solution should be modern, corresponding to standards and proven by other customers. Therefore MoH is looking for ready made solution which must be localized on Macedonian language Cyrillic alphabet, customized and upgraded if needed to satisfy all requirements. Required subsystems of IHIS:
1. Health Data & Application Center HDAC (Central software, HW, Telecommunication equipment) 2. Patient Health ID & Insurance card, Professional ID Health card 3. HCI subsystem with special software for Health centers and Hospitals hosted in HDAC, including EPR/EHR data, modules for financial, accountancy, administration processes and data analysis 4. Pharmacy subsystem (integration with existing Pharmacy software) 5. HIF subsystem (integration with existing HIF software) 6. Subsystem for National institute for health protection and regional units (Datawarehouse, OLAP, Decision support) 7. Management subsystem 8. eHealth portal
Project will be implemented through several phases according to the implementation plan. Each phase includes detailed analysis and design, development, testing, trainings, putting in production. After each implementation phase maintenance and user support is required.
IHIS Specification
Version 1.2
2.2 Project scope

IHIS implementation is complex project concerning all aspects of the information system starting with hardware and system software for database center, hardware and system software for users (Health Care Institutions also HCIs), telecommunication equipment and services for database center and for users, special software for HCIs and other health related institutions, interfaces for data interchange with other existing systems and institutions, special IHIS equipment (e.g. health insurance card/identification and/or devices), implementing world standards related to health and ICT, several levels of users training, system maintenance and upgrading, other aspects described in this document. Because of this complexity project is divided in to logical implementation phases and subsystems which are described at the end of the document, after all functional and technical requirements are explained.
2.3 Project objectives

Project objectives are divided into short term objectives (concerning functional and technical requirements presented in this document) which should be achieved after implementing IHIS, and long term objectives which should be achieved afterwards. Short term objectives: 1. Establish Health Data and Application Center (also HDAC) in Ministry of Health (hardware, system software, telecommunications, training) central part of IHIS. 2. Integrate Health Care Institutions within IHIS: MoH, HCIs, NIHP, IHP, HIF, Pharmacies 3. Implement central medical/hospital software for HCIs running centrally in HDAC and used through web browsers by HCIs (n-tier architecture, web based) 4. Implement central database and software for NIHP and IHPs 5. Implement interfaces and solutions for integrating with HIF and Pharmacies 6. Establish Central registers and Coding tables for IHIS 7. Provide health insurance card or other identification for insured citizens 8. Implement Electronic Health Record (also EHR) and/or Electronic Patient Record (also EPR) in HDAC according to European standards and best practice 9. Implement e-prescription solution 10. Implement Health Care and ICT related standards and best practice in Europe 11. Provide professional ID card or other identification for professional staff 12. Train IHIS users and professional staff for managing IHIS 13. Provide reliable and scalable IHIS infrastructure and solutions
Long term objectives:
IHIS Specification
Version 1.2
1. DRG Implementation for Hospitals 2. Personalized eHealth portal for patients 3. Telemedicine
2.4 Organization
Contracting authority, other stakeholders and users will set up special project organization for IHIS projects. Next organization chart is showing roles and groups of this project organization. MoH is expecting to run more than one project for IHIS implementation. Also requirements in this document could be divided into more than one project (e.g. Each IHIS subsystem is one project, each IHIS implementation phase is one project to be decided by MoH).
Steering Committee Steering committee has the highest position in project hierarchy. Steering committee consists of key stakeholders members and decision makers. Its role is to fully support program, to supervise program implementation, to provide key business decisions and to ensure budgeting of the program and projects. Steering committee is acquainted with program progress through reports sent and presented by program manager.
Program Manager and Technical Program Manager Program managers main tasks are: planning, project management, reporting to the Program Steering Committee, progress and quality control. Technical program manager is responsible for taking over Program managers tasks in case of his absence. Technical program manager has the same tasks as Program manager. Within these tasks he provides support to Program manager and is responsible for forming technical-technological guidelines, their implementation and for resolving technical-technological issues within projects. Program manager is obligated to report periodically to the Program Steering Committee.
Advisory board Advisory board is Program managers consultation body and it evaluates suggestions and solutions regarding projects. Composition of Advisory board usually stays the same through whole duration of the program and assures verified and uniform solutions. Tasks of Advisory board: handling suggestions for processes and solutions implementation, preparing guidelines for implementation of various solutions. Advisory board has regular meetings with program manager where advisory board is discussing and proposing technical and other solutions for projects.
User representatives group
IHIS Specification
Version 1.2
User representatives group usually consist of representatives of key users of new solution to be implemented through projects. Program manager will regularly discuss project requirements and project results with users.
Project Office Project office provides main expert services for program planning, controlling, reporting and documenting. It performs methodological and administrative tasks in the field of program management.
(Contracting authority) Project Manager and Technical Project Manager Project manager tasks are project planning, project management (delegating tasks, coordination, risk management), reporting and controlling project progress and quality. Project manager is regularly reporting to the Program manager. In the time of his absence Project manager is substituted by Technical project manager. This refers to all tasks and responsibilities of Project manager. Technical project manager also provides support to Project manager and is responsible for forming technical-technological solutions, their implementation and for resolving technical-technological questions, which arise within individual projects.
Providers Project Manager Providers project manager has similar tasks like project manager, but limited to managing project task required from provider. Providers project manager is regularly reporting to Project manager.
Project Group Project group operates directly under project managers leadership. Project group members are defined in the Project initiation document prepared by contracting authority Project manager and confirmed by Program manager. Project group constitutes of contracting authoritys members and external providers members. The main task of Project group is to produce project results.
10
IHIS Specification
Version 1.2
Legend
Person
Program Steering Committee Advisory Board IT, Medical, Legal,
Group Program Manager Technical Program Manager
User Representatives Group
Project Office &Technical support
Project 1
Project Manager Technical Project Manager
Project N
Project Manager Technical Project Manager
Project Group
Project Group
Contracting authority project group
Provider Project Manager
Contracting authority project group
Provider Project Manager
Provider Project Group
Provider Project Group
2.5 Processes
Processes for managing the project will be defined by contracting authority. Most important processes, which will be defined and aligned with above organizational structure, are: project reporting, change management, risk management and quality assurance/management. If needed, presented project organization will be reorganized at the beginning of the project to fully address all important processes for managing the project. Relevant processes, concerning awarded provider, will be presented at the beginning of the project.
11
IHIS Specification
Version 1.2
3 CURRENT STATE OF HEALTH IS IN THE REPUBLIC OF MACEDONIA

3.1 Introduction
In the health sector in the Republic of Macedonia there is no unified integrated information system. The number of IT staff in the health sector is very little, not enough to create conditions for faster development. There is no central body responsible for ICT implementation and monitoring the development of integrated health information system, and also there is no central health database. [3] Computer education of the health care providers is not on a satisfactory level. There is no mass internet use, there are certain exceptions, but mainly dial-up mode is used, and in some institutions there is ADSL connection. Application of information-communication technology (ICT) in the health sector in Macedonia is very much below the European Standards. Health Information system shows significant variables regarding the technical equipment and computer education of the employed. Thus there are health care institutions that fulfill the European standards for ICT development and institutions that completely lack any ICT. The crucial deficiency of HCIs and also others health related information systems in Macedonia is the fact that they are not connected electronically, they do not use unified coding standards, health record standards, ICT standards and central registers, they also use different standard and formats for patient records. Therefore each institution represents a kind of isolated information island which is not capable to communicate with others electronically [7].
3.2 Key findings

Key findings about current information systems are: 1. There is no electronic communication trough the internet between HCIs, HIF, NIHP and MOH and consequently no Integrated Health Information system (IHIS). 2. Reporting on provided services from HCIs to HIF is paper based or in some cases with magnetic media. 3. Weak local area network in HCIs, especially in health centers and some hospitals. 4. The data about HCI services is entered in different information systems up to 4 times no single data entry point. 5. Rare internet access points in HCIs (dial-up or in some cases ADSL). 6. Relatively well established local area network in NIHP and local/regional IHPs and also well equipped with hardware and software. 7. There are few relatively well equipped hospitals and centers with hardware, software and local area network (e.g. , The Institute of Radiotherapy and Oncology Former University Clinical Center of Skopje, Hospital of Orthopedics and Traumatology Ohrid). 8. Lack of IT professional staff in HCIs for further information system development and implementation.
12
IHIS Specification
Version 1.2
9. IT staff in HCIs are mostly working with older IT technologies and are not well educated for implementing new technologies, new IT processes and e.g. security threats on the internet. 10. No strategy, plan or clear vision in HCIs for their information system. 11. Lack of knowledge about health record standards, coding and ICT standards. 12. Different standards or no standards used in local information systems in HCIs. 13. No central institution or body responsible for coordinating, planning, implementing and standardizing health information system in Macedonia. 14. Information systems in HCIs are mostly based on older and non-internet information technologies and environments (e.g. DOS environment) established from 1993 to 2001. 15. No electronic patient card or professional card for patient identification, authentication and checking patient insurance status (still using blue cards/tickets). 16. No central database or integrated system for electronic patient records or electronic health records.
3.3 Current state in Health related institutions in Macedonia

Former University Clinical Centre in Skopje (also UCCS), as the largest educational, researchscientific, health care institution in the country, for many past years has been the first in Macedonia to develop information system. There was several software solutions developed that are still operational. However, in the past years there was not enough maintenance and care taken for further development of the information system in UCCS, thus making it old now, disintegrated and brought in a situation of being not operational. Thus, what is needed is fast and quality intervention aimed to build new Hospital Information System that will further be integrated with the health information systems from the other health care institutions [3]. The Institute of Radiotherapy and Oncology (within former UCCS), as well as the Special Hospital of Orthopedics and Traumatology in Ohrid, there are advanced solutions for the hospital system functioning in both hospitals. They have relatively new medical equipment, functional network and completely operational hospital information system that cover electronically all most important routine procedures for the patients. Current information system of HIF is relatively well integrated and operational. This system is actually hierarchically divided in two levels: central level and branch offices. The data is kept in the central database, and the branch offices use only those data that are of interest to their area of coverage. The establishment of treasury system made possible to establish electronic communication, and exchange of data with the Drug Bureau and State Statistical Office is realized through magnetic or optical media. Currently, under procedure is the procurement of computer hardware, which would make HIF IT system complete and fully operational. National Institute for Health Protection is a referent centre for health statistics and official partner in the national and international organizations (WHO). NIHP has functional ICT equipment, but as in many health care institutions it is necessary to renew and complete it with new ICT equipment. Ten regional Institutes of Health Protection have satisfactory level of ICT equipment; there is partial unification of software applications, almost all of them have ADSL or cable internet
13
IHIS Specification
Version 1.2
access. With the Medical Map Project it was planned to establish communication of NIHP with the other IHPs, and at the same time unified software application. Ministry of Health and Drug Bureau have implemented ICT on a satisfactory level, there is fast internet access, there are developed and upgraded several software applications. Large disadvantage that influenced a lot on the delays in the development of ICT was the inexistence of ICT sector and IT experts in the Ministry of Health, which disadvantage started continuously to be overcome and is now in the phase of forming a team that would work on IHIS implementation. Very soon, also RIHP will have the opportunity to connect to this network that would enable exchange of data with MOH and Drug Bureau. General conclusion is that the least investments were made in the Health Homes. In some of the special hospitals the situation is good, but in many of them the ICT is missing. Situation in the larger hospitals is relatively satisfactory, but there is a need of additional investment in equipment and infrastructure. Most complete system is found in the Institutes of Health Protection and almost all of them are operational, information structure is brought to an operational level and is functional, also with small exceptions, the computer equipment is brought to a level necessary for continuous functioning. Pharmacies are using their own software and hardware to support their business processes for selling drugs, issuing drugs, stock tracking, reporting and others. Information system is running locally for each Pharmacy or in some cases central information system is established for a group of pharmacies belonging to one company (e.g. Zegin). There is no electronic communication between pharmacies and HIF or MoH communication is based on paper and floppy disks according to predefined data structure for reporting.
3.4 Starting point for future IHIS

Current situation analysis of Health IS in Macedonia is showing us that there are many weaknesses but in the other hand also many opportunities to improve situation and also many issues to solve in the future. The lack of integrated health information system could be understood as great opportunity to develop modern and unified system from with solid foundations: there will be less integration with existing systems because they dont exist, unified solutions could be implemented and maintained centrally, central registers and coding tables could be used from the beginning of IS implementation, common standards could be used in all relevant institutions and solutions. The ministry is looking for provider to implement most adequate solution according to current situation and actual requirements presented in this document. The solution should be modern, corresponding to standards and proven by other customers. Therefore MoH is looking for ready made solution which must be customized and upgraded if needed to satisfy all requirements. Ministry and other stakeholders are aware of the IHIS implementation complexity, therefore project will be accomplished through several logical phases defined at the end of specifications.
14
IHIS Specification
Version 1.2
4 FUTURE IHIS SPECIFICATIONS

4.1 Future IHIS architecture
IHIS is central oriented information system with strong networking capacities connecting all relevant institutions and information systems in health sector in Macedonia. Institutions taking part in the system are: MoH, HCIs, HIF (and regional HIF units), Pharmacies, NIHP, IHPs. Institutions will be connected through IP VPN to the central IHIS location, called Health Data & Application Center (also HDAC) which will be placed in MoH. Also backup ADSL connection is planned for critical institutions and applications. Application and modules should be web based with central database located in HDAC. Health related data standards, ICT standards and best practice should be used. IHIS subsystems that should be provided and implemented by selected providers/partners are: 1. Health Data & Application Center HDAC 2. Patient Health ID & Insurance card, Professional ID Health card 3. HCI subsystem, including EPR/EHR data, modules for financial, accountancy, administration processes and data analysis 4. Pharmacy subsystem 5. HIF subsystem 6. (N)IHP subsystem 7. Management subsystem 8. eHealth portal All subsystems of IHIS will be basically implemented and running in HDAC. Subsystems will be used by end users or other existent systems through IP VPN connections. Next schema is showing institutions included in the system and some basic functionality for each institution (see arrows). Beside IHIS subsystems implementation, it is expected from provider to provides other important services during IHIS implementation and production like user training, maintenance, software adjustments (e.g. Integration with existent software solutions in HCIs). Detailed IHIS functional, technical and other requirements, that must be considered by potential providers and implemented if selected according to the procedures, are described further in the document.
15
IHIS Specification
Version 1.2
4.2 General IHIS use case and process description

The usual IHIS process starts with patient who wants to visit general practitioner while having some health problems or needs. Patient should first appoint himself for a visit and after that he visits general practitioner on scheduled term (scheduling patient visits). On arrival patient identifies him self with unique identification (Patient Health ID & Insurance card). General practitioner (GP) uses his professional identification and patient identification to start process within the Health information system. Information system first automatically checks patient ID and insurance. According to GP rights and policies, information system offers to the general practitioner new data stored in EHR central database if any. GP can check new data in EHR or request more detailed data from third health care provider. After medical examination and checking data in the information system, GP can decide on diagnosis and further process. Data about diagnosis, further procedures for diagnosis (e.g. laboratory), doctors note for hospital, treatments or prescribed drugs are all stored in the Electronic patient data (EPR) or EHR central database. After that patient leaves GP and visits other HCIs or accomplishes other examinations if necessary. During next examinations or during staying in the hospital, patient always uses his unique identification document to identify him self, to check insurance electronically and to enable doctors to gain access to his EPR or EHR and after that supplement EPR or central EHR with new medical or other data according to the procedure (e.g. discharge letter, disease). The most important gain of the new integrated information system is unique identification, electronic insurance checking, and access to central EHR database for patient medical data wherever patient uses some medical services.
16
IHIS Specification
Version 1.2
After finished treatments or examinations in several HCIs patient can return to his GP. GP can check all data about treatments or examinations in the central EHR or EPR database, check discharge letter or some other treatment/therapy conclusions. GP can also decide to prescribe drugs to the patient in this case doctor uses information system to select drugs from the register and to confirm (prescribe) drugs to the patient. Data about prescription is stored in the central database and can be used either for Pharmacies when issuing drugs or for statistics on prescribing drugs. When patient gets prescription for drug according to the treatment, he goes to the pharmacy having no paper document or paper prescriptions. Only thing he is carrying is his identification card. Pharmacy information system uses patient identification card to access central database and to gain data on prescribed drugs by the doctor. Pharmacist issues prescribed drugs to the patient and the action is stored in the central database. The central information system, physically located in MoH, will enable HCIs to automatically report to other institutions according to the regulation. All data will be stored in central database and reports could be prepared automatically or semiautomatic and send periodically to other institutions using common interfaces.
4.3 Health Data & Application Center HDAC

4.3.1 Introduction of HDAC
Health Data & Application Center is the heart of IHIS. HDAC will provide software solutions and services for institutions connected to the system. All solutions/subsystems will be hosted by HDAC and used by users through internet via web browsers or in some cases through special interfaces to existent systems (e.g. HIF). HDAC must also host central database with EHR/EPR and other relevant personal, medical, analytical, statistical, financial and administrative data. In later phases it should support also DataWarehouse. To ensure full functionality of HDAC, providers will have to implement all subsystems described in this document and set up efficient Hardware, System Software and Telecomunication equipment to support subsystems. MoH will assure proper location, telecommunication services and people (2 4 people) to help establish HDAC and later managing IHIS implementation and production activities. During first phase of IHIS implementation, selected provider should prepare requirements for location and telecommunication services according to offered solution.
4.3.2 Hardware
HDAC will be a heavy duty data and application center and therefore sufficient processing resources and storage capacity must be ensured. Provider must offer necessary hardware equipment to support all IHIS subsystems in testing phase and production phase: Production phase (Heavy duty, reliable equipment with sufficient redundancy): applications servers (clustering, load balancing) internet servers (clustering, load balancing)
17
IHIS Specification
Version 1.2
database servers & storage (clustering, SAN) caching servers business Intelligence / Reporting server backup/Management server other if needed according to offered solution requirements
Testing phase (less powerful): applications servers internet servers database servers other if needed according to offered solution requirements
Other equipment: Rack(s) for hardware and telecommunication equipment Hardware for backups, Backup subsystems (in later phases backup location will be established) UPS (sufficient for 15 minutes operating without power), electricity generator for backup power will be ensured by MoH in chosen location.
4.3.3 System Software, servers software and licenses

System software, server software and licenses must be included in offer: Network operating system + licenses Operating systems for servers + licenses Software for database server + licenses Software for application and internet server + licenses Software for tracking/controlling the usage of system resources Software for tracking/controlling the usage of network resources Special firewall software if needed (depending on solution) Antivirus software for servers (central automatic update for servers) Backup software + licenses SAN software + licenses other if needed according to offered solution requirements + licenses
18
IHIS Specification
Version 1.2
4.3.4 Central IHIS1 software, database and interfaces

Provider must offer and implement software for all subsystems described in this document. Software will be placed in HDAC and accessed by users through IP VPN connections using only web browsers; in case of interfaces to other systems (e.g. HIF), XML exchange format or direct connection to central database will be used. All software subsystems are described further in the document: Patient Health ID & Insurance card, Professional ID Health card HCI subsystem, including EPR/EHR data, administration processes and data analysis Pharmacy subsystem HIF subsystem (N)IHP subsystem Management IS eHealth portal modules for financial, accountancy,
Offered Solutions (subsystems), designed and implemented on the basis of Service Oriented Architecture (SOA), will be preferred. Subsystems must satisfy requirements for mission critical operations (high availability and high reliability), wide range scalability (national level roll-out), high security and data protection standards compliance and to support efficient system management for performance stability and accountability. For maximizing adjustability and scalability of offered solution it is desired to use BPMN (for modeling processes), BPEL and Enterprise Service Bus (ESB), Service Oriented Architecture (SOA) and J2EE5.
IHIS central database requirements HDAC must host central database for all IHIS subsystems. Therefore database content should be: medical data, personal data, EHR/EPR data, analytical and statistical data, financial and administrative data and other Database must be relational or object-relational Detailed description of data, relevant to each subsystem, is described further in the document where subsystems are described. Central database should be physically implemented with storage system or other heavy duty data management solution offered by the awarded provider. Central database should be logically divided into four logical databases: medical and personal data, reporting and statistical data, other data (financial, accountancy), log files. In later phases also Data warehouse will be implemented.
Integrated Health Information System
19
IHIS Specification
Version 1.2
Central database will include central registers and central coding tables needed by subsystems. Registers and coding tables are described further in the document. Central database must enable log files for tracking each user activity (user, activity, date&time, application, data) Provider will have to provide detailed documentation on database including minimum: database schema, described entities & attributes, keys, integrated restrictions, user rights and triggers. Awarded provider will have to implement backup system (backup system, backup unit, backup media) and describe backup/restore procedures. In later phases full disaster recovery policy should be implemented and also physical backup location (hot location). Backup location with fully redundancy servers and other equipment, fully replicated database, hot location totally ready and capable for operation in case of primary location failure. MoH will ensure phisicall location with proper other equipment (air conditioning, electricity, electricity generator, telecommunication lines to primary location, physical security)
Central interfaces: Central interfaces will be implemented for data interchange between existing software solutions (e.g. HIF) and new IHIS/HDAC solutions. Interfaces could use synchronous or asynchronous communication Preferred format for communication is XML based For medical data exchange HL7 v.3 standard must be used Health data communication standard Possible interfaces: interface with HIF, interface with Pharmacies, Interface with existing hospital information systems, interface with Statistical Office, interfaces with relevant national register (e.g. Residents register) Interfaces are described further in document where describing IHIS subsystems.
4.3.5 Common Health and other registers, coding tables

IHIS subsystems must include unified registers and coding tables related to the health care area. Provider will have to implement unified registers and coding tables in four layers: 1. implement registers and coding tables in central database in MoH/HDAC 2. interfaces for managing registers and coding tables 3. integration of registers and coding tables in IHIS subsystems/solutions 4. presentation of registers and coding tables in public eHealth portal (functionalities: preview form for each register or coding list, search form, download option)
20
IHIS Specification
Version 1.2
All registers and coding lists will be maintained centrally in HDAC. Content for registers and coding lists will be provided, verified and maintained by MoH and other competent health care organizations defined in the first phase of the project. Each record in register or coding list must have unique identification corresponding to EU standards and best practice. Provider will have to execute data migration from existent registers to new registers in central database regardless of current form of registers (paper, Excel, database). Verification of data, to be migrated in central database, will be verified by MoH and other competent authorities in Macedonia. Most important registers and coding lists to be included: Register of drugs (data will be provided by MoH, Drug Bureau) Register of herbal medicines (data will be provided by MoH, Drug Bureau) Register of Doctors (data will be provided by Macedonian Medical Chamber) Register of Dentists (data will be provided by Chamber of Dentists) Register of insured citizens (data will be provided by HIF, automatic synchronization must be implemented between HIF register of insured citizens and IHIS/HDAC register) Register of all Health care institutions in Macedonia (data will be provided by MoH) ICD-10 International Classification of Diseases (international standard diagnostic classification) Register of nurses and other medical staff working in HCIs Other registers and coding tables according to offered solution
4.3.6 Standards
The adoption of standards is an essential requirement for improving the quality and usefulness of information for all stakeholder groups, and is of crucial importance in the use of the electronic healthcare record. Most important standards to be implemented: application protocol for electronic data exchange in healthcare environments HL7, version 3 RIM EHR/EPR standards have to be based on HL7 v.3 RIM and combined with the best EU practice and other standards if necessary (oSIST prEN 13606, EHRcom, CDA, IHE XDS, MML, SR, XDS). Standard should define: structure and contents, using, sharing, and exchanging electronic health records. Final decision on standards and some adjustments must be a part of first implementation phase, according to offered solution and actual local needs. ICD-10 International Classification of Diseases (international standard diagnostic classification) CEN _ENV 12967: Healthcare Information System Architecture (HISA) Identification standards for patient should be used (described further in the document) DICOM Digital Imaging and Communications in Medicine (offered system should be prepared to include DICOM if decided to implement it in later phases) Other standards according to offered solution
21
IHIS Specification
Version 1.2
4.3.7 Security and User rights management

Due to the extremely sensitive and confidential data related to the inner workings of the Health care institutions, which is usually classified up to the highest level, a special attention should be paid to the design and the implementation of security and privacy mechanisms. IHIS/HDAC must assure physical and system/software security. Physical security for HDAC will be ensured by MoH. System or software security must be implemented in IHIS subsystems by awarded provider. Principles of system security and system components that should be implemented: physical security (to be ensured by MoH) firewall antivirus programs solution for detecting and preventing attacks from the network, e.g DoS (Denial of Service) to access any subsystem (or part of any subsystem) of IHIS minimum username and password should be required (except for the public non-personalized portal), for professional staff also in combination with PID professional identification card each active IHIS user must have unique ID and his own username and password user activity must be recorded in log files in HDAC
User rights management and system monitoring will be performed by local staff in HDAC center. During the first phase of implementation, provider will have to perform training for local staff in HDAC center to gain optimal knowledge for managing security issues and user rights management. It is demanded that user rights management system is opened for changes in legislation and user right policy. Currently the health related legislation in Macedonia is in the process of adjustments and modernizing and therefore some new access rights to medical and personal data will be introduced shortly.
4.3.8 User activity tracking User & activity LOG files

Each user activity must be tracked and stored in log file, starting from user login until log out. Minimum data to be stored for each user activity: Professional user ID (e.g. doctor), subsystem/application, activity (read, write, change, delete), patient ID, data changed or accessed, date&time. Interface for user activity tracking and log file controlling must be implemented by provider. The monitoring and record keeping concerning any use of the system by anyone should be on the 24/7 basis, generating a security trail for analysis, review, evaluation, and system checking. The automatic processing of the logs should be subject to searches for access and usage behavior patterns and consequently semantic reports. Once a particular transaction has been saved, it should not be possible to delete it (i.e., a new transaction must be initiated to change the data, but the original transaction should still be accessible).
22
IHIS Specification
Version 1.2
4.3.9 Telecommunications
Telecommunication lines for HDAC and contracts with telecommunication providers in Macedonia will be performed, financed and agreed by MoH. Awarded provider for IHIS solution will have to ensure and install adequate telecommunication equipment in HDAC center. Beside HDAC telecommunication equipment it is required from the provider to set up or verify local area networks in HCIs according to the implementation plan (described in more detail further in the document where describing HCI subsystems and implementation plan). Required equipment for HDAC to be provided: High performance gigabit switch(es) (incl.: quality of service SW, web based access, virtual LANs) Router(s) (enabling static IP, DHCP, IP VPN connections) Patch panel(s) CAT6 Patch cords CAT6 Other equipment according to offered solution needs
4.3.10 System backup & Disaster recovery

Provider must offer and implement hardware equipment and software for periodical data and system backups. Backups will be managed in HDAC by local staff. Backup media will be stored in other location outside HDAC. During the first phase of implementation, provider will have to perform training for local staff in HDAC center to gain optimal knowledge for managing backup/recovery processes. During first phase of implementation, provider will have to prepare document describing procedures for backup/recovery. In later phases, according to the implementation plan, provider will have to establish fully functional backup location (hot location) with all hardware, software, solutions and other equipment. Communication lines will be ensured by MoH, backup location (geographical location in Macedonia) will be agreed between MoH and provider. Parallel to backup location set up provider should prepare complete document describing all processes for disaster recovery, business continuity and contingency planning.
4.3.11 Data Migration

Provider will have to migrate data from existent systems and databases if needed to new IHIS database. Existent sources of data which should be considered carefully, filtered if necessary, normalized if necessary and then migrated into new database: Register of drugs (Drug Bureau) Register of herbal medicines (Drug Bureau) Register of Doctors (Macedonian Medical Chamber) Register of Dentists (Chamber of Dentists) Register of insured citizens (HIF) Register of all Health care institutions in Macedonia (data will be provided by MoH)
23
IHIS Specification
Version 1.2
Register of outpatient and inpatient services Register of Nurses and other professional health care staff Others
MoH and other institutions will provide the latest existent data which is worth of migrating to new platform. Migration (either with software interfaces or manually) should be implemented by provider.
4.3.12 HDAC organization

MoH will dedicate 2 4 educated staff with minimum 5 years of experience in managing processes in datacenters. They will be competent for strategic processes of IHIS implementation and strategic development in the future as well as operation procedures in data center (e.g. backups, traffic monitoring). HDAC center will bi placed within MoH.
4.4 Patient Health ID & Insurance card, Professional ID Health Card

4.4.1 Health insurance card and patient identification
IMPORTANT NOTICE: Designing, printing and ID cards delivery IS NOT REQUESTED with this tendering procedure and should not be included in to the offer. It is required from the provider to assure software solution which will be capable of using bar code cards and standard bar code readers. For ID cards and bar code readers there will be another tendering procedure parallel to this tendering procedure. Provider will have to establish subsystem for health insurance and patient ID card (also HIPID card). HIPID Subsystem must be integrated with other IHIS subsystems (e.g. for patient input or output, HIPID card should be used in combination with professional staff identification). Subsystem will have to be designed and aligned with current information system on HIF, where the register of all ensured citizens already exists and each patient has his/her own insurance number. The most important functionality enabled by HIPID will be patient identification and checking patient insurance status - patient identification number and patient insurance number have to be linked. Patients will have to use HIPID card for each contact with health care institutions, pharmacies, IHPs and HIF in needed. This card will be unique identification for single citizen of the Republic of Macedonia. It is decided that HIPID card will carry only basic personal and ID data with no chip on it. All other personal and medical data will be stored in central database and could be accessed from each institution connected to the IHIS. The final decision of MoH and other stakeholders is to implement bar code card with basic written data on it. Data, that will be printed on bar code card or coded in bar code, will be defined at the beginning of the project by MoH and discussed with the provider.
24
IHIS Specification
Version 1.2
4.4.2 Professional staff identification

IMPORTANT NOTICE: Designing, printing and ID cards delivery IS NOT REQUESTED with this tendering procedure and should not be included in to the offer. It is required from the provider to assure software solution which will be capable of using bar code cards and standard bar code readers. For ID cards and bar code readers there will be another tendering procedure parallel to this tendering procedure. Provider will have to assure software solution for professional staff identification card (PID card) which will be similar to HIPID card with basic personal and professional data. PID cards must be integrated with other IHIS subsystems (e.g. for patient input or output, HIPID card should be used in combination with professional staff identification). Professional staff will have to use PID cards for each contact with patient. This card will be unique identification for professional of the Republic of Macedonia. IHIS must be implemented in a way that professional staff will use their PID in combination with their username and password to access HCI subsystem and functionalities. Data, that will be printed on bar code card or coded in bar code, will be defined at the beginning of the project by MoH and discussed with the provider. Types of professional staff which will receive PID: general practitioner doctor specialist physiotherapist nursing staff laboratory assistant pharmacist other staff defined by MoH
4.5 HCI subsystem

4.5.1 Introduction of HCIs subsystem
Provider must offer and implement web based IHIS subsystem for HCIs. Web based applications and modules will be hosted in HDAC using central database with decided EHR/EPR standards. HCI subsystem must provide modern information services for HCIs. It will have to support all relevant medical processes, administration processes and data records for Health homes (centers) and also common medical processes and data records for Hospitals and other HCIs with purpose to use all advantages of central EHR/EPR database. Functionalities are described in more detail further in this chapter 4.5.
25
IHIS Specification
Version 1.2
4.5.2 Hardware, System software and telecommunication for HCIs

IMPORTANT NOTICE: Hardware, System software, telecommunication equipment and installation services for equipment for HCIs are not requested with this tendering procedure and should not be included in to the offers. The specification in this chapter should be used only as information for bidders to have clearer picture of the whole project complexity. Another tendering procedure for HCIs Hardware, System software and telecommunication equipment and installation will start parallel to this tendering procedure.
Most of Health homes (centers) do not possess adequate hardware, system software and telecommunication equipment and capacities to join IHIS and start using HCIs subsystem through web interfaces or any other complex system. Therefore provider will have to set up local area networks for Health Homes (e.g. installing router, cables, end connectors), install hardware equipment (personal computers, printers, bar code readers) and system software according to the implementation plan within special tendering procedure not part of this tender. Local area network should be at least CAT 5e standard, minimum 100Mbit/s. Communication lines between HCIs and HDAC will be provided through IP VPN (static VPN) in the network provided by MoH. Also backup ADSL line must be established in case of primary connection failure backup lines will be also provided by MoH or HCIs and are not a part of the tender. Communication lines and services will be coordinated and agreed between MoH, HCIs and telecommunication providers in Macedonia in the first phase of implementation. Some hospitals already possess adequate hardware, system software and LAN equipment and others not. According to the implementation plan also Hospitals will be included and provider will have to install missing hardware, LAN and system software in Hospitals if necessary not part of this tender. Hospitals, which will decide to use their own software and will connect to IHIS using interface (described further in the document), will have to upgrade their software, servers and local communication equipment by them selves. It this case only advanced communication lines between Hospitals and HDAC (not part of this tender) will be provided by MoH and some computers workstations with bar codes readers should be installed by the awarded provider according to the implementation plan.
Local area network in HCIs should be implemented or upgraded by the awarded provider in special tendering procedure not part of this tender. Needed equipment for local area network (e.g. for one building): Router Switch(es) UPS Patch Panel Patch and link Cables Rack (sized for all equipment described above + minimum 10U free space) LAN Wiring: CAT.5E, STP
26
IHIS Specification
Version 1.2
Office equipment (metal canals, RJ-45 jacks with anti dust cover, cables, grounding according to standards, standard electrical jacks, standard electrical jacks for UPS, testing, measuring)
Standard working place: element with two RJ-45 jacks with anti dust cover (left jack for data, right jack for telephone) one element with 3 standard 230V jacks one element with 3 UPS 230V jacks labels for data and telephone jack (numbers related to patch panel) for 10m2 2 standard working places are required, for each next 7m2 aditional 2 standard working places are required (e.g. for 17m2 office, 4 standard working places must be provided)
Important common characteristics to be included in designing and implementing LANs in HCIs: LAN will be used for two purposes: q q Web based IHIS applications hosted in HDAC center with high security demand General access to the internet (traffic splitting)
Connection from HCIs to HDAC center will be based on IP VPN 10/100 Ports for end users, additional 10/100/1000 Ports on Switch Integrated security solution (Firewall, VPN SSL, Authentication, Encryption, MAC Based Filtering, URL Filtering, Access Control, System Log, traffic and bandwidth limiting, Web based monitoring software) Free VPN tunnel connections must be available Each floor must have its own data switch Equipment (Router) must be adjustable to enable different adapters (copper, optic fiber) Autonomy (UPS) minimal 15 minutes VoIP Ready (upgradable with VoIP modules and IEEE802.3af standard) VLAN Ready WLAN ready (upgradable with WLAN modules, 802.11b/g/n standard) All equipment rack mountable Respecting local (Republic of Macedonia) standards for wiring FTP and 230V.
Awarded provider for this equipment will have to prepare detailed LAN schemas, wiring schemas, LAN components characteristics and cost calculation at the beginning of the project for each building or location. After inspecting and approving plans and calculations by MoH, provider will have to install required hardware.
Standard specification for workstation that should be provided and installed by provider according to the implementation plan (not part of this tender) is:
27
IHIS Specification
Version 1.2
The proposed PC configurations must have minimum score of 270 under the SYSmark 2004 SE Benchmark (Sysmark 2004 Rating) and 210 under the SYSmark 2004 SE benchmark (Office Productivity (Overall)). Benchmarks and scores are available on www.bapco.com. CPU should be 64 bit (emulated processors would not be acceptable) and working at designated CPU frequency by the CPU vendor. CPU must have at least three years warranty from the original CPU producer and this must be documented properly by the original CPU producer. Memory: DDR, minimum 1Gb RAM, maximum 4Gb Disk: 200 Gb disk space or more; ATA or SATA or SATA II; minimum 7200 rpm; minimum 8MB cache Graphics: minimum 256 Mb (not shared), supporting native resolution for 15 and 17 monitors, DVI port CD/DVD: DVD ROM + CD R/W (combo drive) Network: 10/100/1000 Mbit/s Fast Ethernet Network Card Sound: Integrated sound card Ports and interfaces: minimum: 6xUSB 2.0, 1xSerial, 1xPS/2 Mouse, 1xPS/2 Keyboard, 1xParalel, 1xVGA, 1xDVI-Out, 1x MIC audio, 1xLine out Audio, 1xRJ45 Mouse & Keyboard: 1xstandard mouse, 1xkeyboard Standard BarCode Reader: 1x (for reading bar codes printed in Health insurance card and patient identification and Professional staff identification) Monitor: LCD 17 supporting native resolution for 17 monitors Operating system: MS Windows XP Pro or other equivalent with similar functionalities; Software for rescue and recovery Warranty: 3 years minimum
Standard specification for printer that should be provided and installed by provider according to the implementation plan is: Resolution: 600 x 600 dpi Pages per minute: minimum 16ppm, or better Memory: minimum 8 MB, or better Connection: USB 2.0 Software: Drivers for Windows XP Toner: Toner cartridge included Warranty: 1 year minimum
28
IHIS Specification
Version 1.2
4.5.3 Special medical/hospital software

Special medical software for Health homes and Hospitals will be hosted in HDAC and used by professional medical staff thorough web browsers (solution should be adapted for latest version of Internet Explorer or Mozilla). Software functionalities for Health Homes: Software solution must support all relevant areas in the primary Healthcare. Minimal requirement is to support next areas: Common functionalities (functionalities that are commonly used through different sectors, outpatient clinics, doctors, specialist or nurses according to security schema): q q q q q Patient scheduling Patient identification Assigning patients to chosen doctor as family/personal GP chosen physician Accessing patient records and archives in central EPR/EHR database Updating patient records in EPR/EHR database according to specific medical area (for each appointment, visit or performed service for the patient) Updating specific and essential medical notes for patients in central database (e.g. chronic disease, allergy, disability,..) Creating, updating and deleting personal patient data in central database according to security schema (e.g. for general practitioners, family doctors). Once a particular transaction has been saved, it should not be possible to delete it (i.e., a new transaction must be initiated to change the data, but the original transaction should still be accessible). Using central registers and coding lists (e.g. central drug register, central register of HCIs, ICD-10, coding list of provided services required by HIF) Ordering patients (Order Entry) to in-house diagnostics and examinations. Connection with laboratory and other In-house diagnostic and examination units (e.g. X-Ray Organizational unit) reporting test and examination results from diagnostic and examination units to other units (results will be stored in central database). Referring patients to other specialist or examinations to other HCIs Drug prescription General reporting (on provided services, scheduling, costs) and reporting for specific areas in primary Healthcare Preparing and issuing invoices for patients which are paying for services fully or partly by them selves. Preparing reports or entering data for NIHP, HIF or MoH only for data which could not be generated automatically from existent records for patient or services in central database.
q q
q q q
29
IHIS Specification
Version 1.2
Specific functionalities supporting processes and data records for: q general practitioners (supporting processes and data records for general practitioner) dental practitioners (supporting processes and data records for dental practitioners) gynecological practitioners laboratory physical therapy rescue services (transport) emergency services X-Ray services ultrasound services neurology dental technique psychiatry orthodontics pediatric preventive medicine for children and schools preventive occupational medicine home visits of general practitioners and nurses other areas and services commonly provided by health homes
q q q q q q q q q q q q q q q q q
Software solution must support basic functions for practitioners: professional staff registration and identification, patient scheduling, patient identification with HIPID card, keep records on diagnosis and provided services for patient, track data for each patient in EHR/EPR central database according to user rights, drug prescription (e-prescription module), laboratory results preview, etc (described above: common functionalities). Special solutions and added value for all special areas of primary health care is desired. E-prescription must enable doctor to prescribe drugs electronically without any paper. Data about prescribed drug must be stored in central database. Reporting to HIF and NIHP must be implemented electronically and automatically if data required for reporting already exists in central IHIS database reports should be generated automatically and stored in central IHIS database (later Data Warehouse). Reporting formats and forms will be presented to the provider after award of the MoH contract. Software must be adjustable in a way to implement DRG or to connect with DRG subsystem, which is planned to be implemented in year 2008.
30
IHIS Specification
Version 1.2
Health homes will be connected to the IHIS regarding implementation plan presented in this document.
Software functionalities for Hospitals: Some hospitals already have their own applications or information system, also clinics in Clinical Center in Skopje, other hospitals have weak software solution or they dont use it at all. It is required from provider to provide basic software solution with common functionalities for hospitals. Software should also be web based (users should access software through web browser). Software must use central EHR/EPR database to store all relevant data according to chosen EHR/EPR standard. Reporting to HIF and NIHP must be implemented electronically and automatically if data required for reporting already exists in central IHIS database reports should be generated automatically and stored in central IHIS database (later also Data Warehouse). Reporting formats and forms will be presented to the provider after award of the MoH contract. For hospitals and clinics which already use their own systems and are capable to communicate with other systems, it is required from the provider to prepare one unified interface for all existent solutions. Interface must be implemented according to EHR/EPR and HL7 v.3 standard and according to reports that hospitals have to send to other institutions (e.g. HIF). XML format is preferred for communication. Existent hospital system upgrade will be carried out by hospitals themselves, regarding to specifications of software interface prepared by the provider therefore existent hospital software adjustment is not required from provider. Hospitals, which will decide to use their own software and will connect to IHIS using interface, will have to upgrade their software, servers and local communication equipment by them selves. It this case only advanced communication lines between Hospitals and HDAC (not part of this tender) will be provided by MoH and some computers workstations with bar codes readers should be installed by the awarded provider according to the implementation plan (hardware installation for HCIs in not a part of this tender).
Basic Software solution for hospitals: Software solution must support relevant areas in Hospitals. It is required to provide basic and common functionalities for Hospitals (e.g. ADT (Patient Admissions/Discharge/Transfer) data and functionalities). Its is important for Hospitals to use central EPR/EHR database and all benefits offered. Minimal requirement is to support next areas: Common functionalities (functionalities that are commonly used through different sectors in Hospitals according to security schema): q q Patient scheduling, scheduling appointments Patient identification and registration (identifying patient, registering at reception desk, selecting doctor) Internal patient management In-Patient management Recording provided services for patient, medicines, materials at individual patient level
31
q q
IHIS Specification
Version 1.2
Referring patients to examinations and other outpatient clinics, recording and tracking results Transfers Ordering other services, medicines, materials for patient Out-patient administration and management, recording and tracking results Accessing patient records and archives in central EPR/EHR database Updating patient records in EPR/EHR database according to specific medical area (for each appointment, visit or performed service for the patient) Updating specific and essential medical notes for patients in central database (e.g. chronic disease, allergy, disability,..) Preparing discharge letters and notifications Basic functionalities and processes for financial and inventory calculations Using central registers and coding lists (e.g. central drug register, central register of HCIs, ICD-10, coding list of provided services required by HIF) Connection with laboratory and other In-house diagnostic and examination units (e.g. X-Ray) General reporting (on provided services, scheduling, costs) and reporting for specific areas in primary Healthcare Preparing and issuing invoices for patients which are paying for services fully or partly by them selves. Preparing reports or entering data for NIHP, HIF or MoH only for data which could not be generated automatically from existent records for patient or services in central database.
q q q q
q q q
Hospitals will be connected to the IHIS regarding implementation plan presented in this document.
4.5.4 Financial, accountancy and administrative solution FAAS

It is required from provider to provide basic software solution with common financial, accountancy and administrative solution for health centers and hospitals. Software should be web based (users should access software through web browser). Software must use central IHIS database in HDAC to store all relevant data for administrative and accountancy processes and to use central registers and coding tables. Software must be adjustable in a way to implement DRG in later phases. Financial, accountancy and administrative solution (FAAS) must be tightly integrated with special medical and hospital information software described above. FAAS must use same registers, coding tables and other relevant data wherever possible to avoid double manual data entry and to process data more efficient. Reporting to HIF must be implemented electronically and automatically if data required for reporting already exists in central IHIS database reports should be generated automatically and
32
IHIS Specification
Version 1.2
stored in central IHIS database. Reporting formats and forms will be presented to the provider after award of the MoH contract. Some health centers and hospitals already have their own applications or information system for administrative and accountancy processes. For HCIs which already use their own system and its capable to communicate with other systems, it is required from the provider to prepare one unified common interface. Provider will have to develop only one unified interface according to data interchange standards. All existent systems will have to adjust their logic to communicate with this standard Interface. Interface must enable HCIs to report required administrative and accountancy data to the central IHIS database. Basically this interface should be developed on the basis of reports required by HIF. Interface should use XML format for data exchange. Reporting formats and forms will be presented to the provider after award of the MoH contract. Existent HCIs system upgrade will be carried out by HCIs themselves regarding to specifications of software interface prepared by provider therefore existent software adjustment is not required from provider. HCIs, which will decide to use their own software and will connect to IHIS using interface, will have to upgrade their software, servers and communication equipment by them selves. Required modules and functionalities of FAAS: General ledger q Standard functionalities with standard reports
Managing payments and invoices (accounts payable, account receivable) q Standard functionalities with standard reports
Managing partner contacts and partner basic data used for payments and invoices Material ledger with small inventory support q Standard functionalities with standard reports
Asset Management q Standard functionalities with standard reports
Inventory management including stock management q Standard functionalities with standard reports
Hospital pharmacy inventory management q q q q Standard functionalities (e.g. ordering, stock, costs,) with standard reports Integrated with described software solution for hospitals and health centers Sending material and drug orders to HIF (interface with HIF solution is required) Reporting to HIF according to the HIF rules and the list of positive drugs
Human resource management including module for managing salaries/payrolls q Standard functionalities with standard reports
Procurement, purchasing, ordering module q Standard functionalities with standard reports
Basic tools for analyzing (report), planning and forecasting

33
IHIS Specification
Version 1.2
Software solution must be fully integrated with software for hospitals and health homes. It is required to record and track all expenses for provided medical services, material and other costs for each patient. The solution must enable functionality to prepare invoices for patients. Costs for invoices must be calculated automatically from recorded costs per patient and according to the patient health insurance status and rules for refunds. Recorded services per patient, materials, invoices and all costs per patient will be stored in central database and must be accessible to HIF for further processing in HIF information system (interface to HIF is required). Software must be implemented and adjustable in a way to implement DRG or to connect with DRG subsystem, which is planned to be implemented in year 2008. Supporting other basic financial, accountancy and administration operation needed to run business in hospitals and health centers. Solution must support standard reports for all information areas and dimensions covered in the solution. Solution must also support custom reports defined by users through several parameters (e.g. period, cost center, material, partner) Solution must use central registers and coding tables in HDAC (e.g. register of all HCIs, register of HCI staff,) Solution must be integrated with medical/hospital information system offered by the awarded provider. Solution must use central database in HDAC. No manual data entry/transfer from medical/hospital information system to financial and accountancy system is allowed or vice versa. If data already exists in central database it should be used or linked automatically for further processing.
4.5.5 Database
All personal data, medical data, accountancy data, administrative data, reports and other relevant data for this subsystem (HCI subsystem including EPR/EHR) must be stored in central database in HDAC. Local databases physically placed in HCIs are not planned. Database requirements for Special medical/hospital software and Financial, accountancy and administrative software: Database will be placed in HDAC central database center, therefore requirement for central HDAC database, described in 4.3.4, must be fulfilled, Database for Special medical/hospital software and Financial, accountancy and administrative software must: q q use central registers and coding tab in HDAC store medical data, personal, data, EHR/EPR data, transactional data, financial data, accountancy data other administrative data store all relevant data produced by Special medical/hospital software and Financial, accountancy and administrative software
34
IHIS Specification
Version 1.2
q -
implement EHR/EPR record according to chosen standard and offered solution
Analytical, statistical and other analysis related data should be stored in central Datawarehouse. Use standards presented in the chapter for HDAC database.
4.5.6 User interface requirements

User interfaces have to be designed in a way that all requirements are met. Bidder should follow guidelines and recommendations provided by World Wide Web Consortium (W3C), practices and recommendations of web portal graphic design and also Web Accessibility Initiative (WAI) guidelines. User interface should be standardized as much as possible, attractive and user friendly. Graphic design has to be provided by the bidder but will be adjusted through a process of cooperation between contractor and contracting authority if needed. Basic user interface requirements for HCIs: Web solutions must be translated to Macedonian language Already developed solutions must be localized for Macedonia Register and code tables, and all software interfaces should be on Macedonian language (Localization) Web interface must use Cyrillic characters Provide data entry with language specific symbols for each one of supported languages Web interface should not include animations, flash, larger graphics or other elements demanding higher communication capacities Graphical elements without informative value should not stand out, occupy key page space or significantly affect page loading times. Maximal response time on user action is 5 seconds User interfaces must unified regarding colors, fonts, links, buttons, field length all parts of interface should have a unified look (colours, fonts, navigation etc.). Navigation menu, help etc. should always be in the same place. After 15 minutes of user inactivity web interface must require user re-login and entering password TAB Key must be enabled to navigate through fields in web form Provide access to contents in as few steps as possible Each of the different message groups has to have a uniform and consistent design (e.g. error messages, confirmation messages) Provide selection menus (instead of edit fields) wherever possible Automatic checking of entered data has to be included (e.g. entry of a past date should be disabled) entry errors have to be announced as soon as possible and a user should be pointed to the place of error
35
IHIS Specification
Version 1.2
Navigation has to be clear, consistent and as simple as possible. Global position within the portal has to be evident at all times Simple fonts should be used through the whole portal (e.g. Tahoma, Verdana). Font size should be large enough to allow reading without a special effort.
4.6 Pharmacy subsystem

4.6.1 Introduction of Pharmacy requirements
Pharmacies already use their own information systems which differ from one pharmacy to another. In some cases information centers are established for more pharmacies belonging to one company. Current systems are supporting all basic functions of drug issuing, selling drugs, stock updating, drug register, internal reporting and also reporting for HIF and MoH in electronic Excel format (exporting data) or in printed form. New IHIS must introduce e-prescription module for pharmacies that will be web based and accessed only with browser. Dynamics of connecting pharmacies to the IHIS system is evident from IHIS implementation plan presented in this document.
4.6.2 Hardware, System Software and licenses, Telecommunication

Module for e-prescription will be web based application running in HDAC infrastructure and central database. E-prescription solution will use the resources of HDAC. Pharmacies will have to upgrade their communication lines (IP VPN, static IP address), communication equipment and hardware if necessary by themselves.
4.6.3 Software solution for Pharmacies & Interfaces

It is required from provider to set up e-prescription solution which will enable doctors to prescribe drugs to the patient electronically within integrated module in HCIs subsystem. E-prescription will be stored in the central database connected to other patient related data. It is required also from the provider to: set-up e-prescription web module for Pharmacies which will enable pharmacists to issue drugs after patient identification with HIPID card in the Pharmacy to develop web module for Pharmacies which will enable pharmacies to process drug orders to HIF (for drugs from positive list)
Another option, which is also required from the provider, is to develop unified interface for eprescription data exchange between central database and pharmacy existent system. In this case provider should develop one unified interface and prepare protocol description for data interchange and security issues. Interface must enable pharmacies to retrieve and update e-prescription data in central database periodically (e.g. 5 minutes) or on demand if needed. Also in this case Pharmacies will have to upgrade their communication lines, communication equipment, software and hardware if necessary by themselves.
36
IHIS Specification
Version 1.2
E-prescription solution must also enable generation of automatic reports from each pharmacy according to requirement from HIF (for positive list) and MOH reports should be generated automatically and stored in central IHIS database (later Data Warehouse). Reporting formats and forms will be presented to the provider after award of the MoH contract.
4.7 HIF subsystem

4.7.1 Introduction of HIF requirements
HIF will require many data (e.g. drug orders from pharmacies) and reports (automatic and manual reports from HCIs and pharmacies) stored in central IHIS database. Also IHIS system will need data from HIF system (e.g. citizen insurance status, register of insured people) to enable all expected IHIS functionalities to the users. Therefore it is required from awarded provider to develop special interfaces from IHIS central database to HIF information system and vice versa.

Interfaces between IHIS central database and HIF system will have to use HDAC central infrastructure. No additional hardware, system software or telecommunication equipment is planned. HIF have recently installed new hardware in the central HIF location, therefore no upgrades are needed on HIF side. Also HIF regional units (branch offices) were modernized regarding HW equipment recently.
4.7.3 Interfaces for HDAC HIF communication

Updating and data exchange between IHIS central database and HIF database must be executed automatically and periodically using developed interfaces. It is required from provider to develop special web interface to monitor data exchange, manage exchange periods or to start data exchange on demand. Interfaces for data interchange between HDAC central database and HIF database to be developed: data interface for updating patient insurance register and patient status in IHIS central database, data interface to acquire drug orders form central IHIF database to HIF system data interface to acquire reports from HCIs and Pharmacies on costs, provided services and issued drugs from positive list, data interface for updating central registers (e.g. drug register) other interfaces according to HIF or IHIS needs
Interface development should be based on current paper reports (described further) and possibilities for optimization offered by central database in HDAC. Data interchange should be
37
IHIS Specification
Version 1.2
optimized as much as possible: no extra data entry required for reporting, no paper reporting, automatic reporting and data interchange. Current reporting documents from HCIs and Pharmacies to HIF: Primary Health care institutions q Primary health care institutions chosen physicians, reporting monthly to HIF branch office (electronic form Floppy disc) Report for performed services Report for application of ampoule therapy Calculation for current month and year Report for planning targets (at the beginning of quarter) Report for accomplished targets (at the end of quarter) Secondary Health care private sector q Stomatology units, reporting monthly on hard copy Total invoice for the performed services Specifications per doctor for performed services per insured Referrals to secondary health care institution Confirmation for contribution payment Additional documents depending on the sort of special service q Secondary health care office (internal medicine, eye diseases, medical rehabilitation etc.) reporting on hard copy Quarterly to HIF central office: Calculation of the performed health services volume Quarterly to HIF central office: Calculation of the planning and realizing goals through the results of the performed work Monthly to the appropriate branch office: Invoice Monthly to the appropriate branch office: Daily report for the total of the performed health services Monthly to the appropriate branch office: Calculation for performed policlinic surgery services of the insured Monthly to the appropriate branch office: Referrals to secondary health care institution Monthly to the appropriate branch office: Confirmation for contribution payment Secondary Health care public sector q Policlinic health care office-ambulance, reporting monthly to HIF branch offices on hard copy:
38
IHIS Specification
Version 1.2
Total invoice with performed services of the insures Calculation per patient with services and amount Referral to secondary health care institution Confirmation for contribution payment q Policlinic health care office hospital, reporting monthly to the appropriate branch office on hard copy: Total invoice with performed services of the insurees Calculation per patient with services and amount (boarding services, operation services, anaesthesia, consumed material, ampoule therapy) Hospital sheet Dismissal sheet Referral to the Hospital Confirmation for contribution payment Additional calculations per offices q Clinical center ambulances, reporting monthly to the appropriate HIF branch office on hard copy: Ambulance calculations per insured Referral to secondary health care institution Confirmation for contribution payment Calculation for the performed surgery secondary review and services q Clinical hospital, reporting monthly to the appropriate HIF branch office on hard copy Invoice per patient (hospital stay, consumed material and services) Evident sheet Hospital referral from chosen physician Drug and medical material list Calculation for performed services Medical report Additional documents from referral of the patient into the different clinics (if necessary) Pharmacies q Pharmacy, reporting monthly to central HIF office on hard copy: Monthly order of the drugs from primary health care list Monthly order of the drugs from hospital health care list
39
IHIS Specification
Version 1.2
Order/delivery review form Schedule list form Report from health offices for undelivered drugs Invoices from suppliers for drug deliverance into the hospital health care (hospitals/health offices) per item q Pharmacy, reporting monthly to the appropriate HIF branch office on electronic form Floppy Report for issued drugs per prescription Specification for issued drugs Planning and analyzing q Monthly reporting to central office on hard copy or floppy disc Proposal budget request to health care offices according to budget circular form Projection of income and outcome Review for budged class 7 payments in health care offices Review of the payments for outcome in health care offices Review of the spent resources from account 4235 for drugs and medical materials DT1 Review of the total accounts payable in health care offices O1 Review of obligations not paid of health care offices O2
4.8 (N)IHP subsystem

4.8.1 Introduction of (N)IHP requirements
National Institute for Health Protection in Skopje is the central institution for collecting and processing health data and reporting (e.g. social statistics and other) on a national level. On the basis of collected data, NIHP is periodically preparing reports, analysis, indicators and other document relevant to public health, WHO or professionals working in health care area. NIHP is currently receiving data from 10 regional institutes for Health Protection in electronic format (CD or DVD) and in paper forms which are entered manually to current NIHP database. On the other side regional IHPs are collecting data from HCIs and other institutions, beside this some data is generated by regional IHPs themselves. In current situation the same data is entered in different databases for several times (up to 4) and there is obvious place for optimization within IHIS system.
40
IHIS Specification
Version 1.2
Current reporting process
HCIs (Health Centers Hospitals, UCCS, Private)
IHPs
National Institute for health protection
HDAC Health Data&Application Center
DataWarehouse, Decission support OLAP, Data Mining, Central Registers, Statistics, Indicators, Proffessional Tools
Future reporting process
HCIs (Health Centers Hospitals, UCCS, Private)
National Institute for health protection
IHPs
With new software solution and database for NIHP and IHPs, which should be implemented by awarded provider, current reporting processes will change. All reports needed by NIHP or HIP will be generated automatically from transactional data in central IHIS database and stored in Data WareHouse in HDAC. On the other side, users in NIHP and IHPs will be using special analysis and reporting tools to analyze data in Data Warehouse, prepare reports, calculate indicators, crossing data registers etc. This software solution and data warehouse solution should be implemented by the awarded provider. (N)IHP subsystem will be implemented according to the implementation plan at the end of the document.

IMPORTANT NOTICE: Hardware, System software, telecommunication equipment and installation services for equipment for HCIs are not requested with this tendering procedure and should not be included in to the offers. The specification in this chapter should be used only as information for bidders to have clearer picture of the whole project complexity. Another tendering procedure for HCIs Hardware, System software and telecommunication equipment and installation will start parallel to this tendering procedure.
It is required from provider (not in this tendering procedure) to upgrade existent hardware, system software and telecommunication equipment in NIHP and IHPs to use modern IHIS solution. Each IHP and NIHP location must be upgraded with new router enabling VPN connection. It is also required to install 10 new workstations for NIHP and 2 workstations for each regional IHP (10 IHPs in whole Macedonia).
41
IHIS Specification
Version 1.2
Standard specification for workstation: The proposed PC configurations must have minimum score of 270 under the SYSmark 2004 SE Benchmark (Sysmark 2004 Rating) and 210 under the SYSmark 2004 SE benchmark (Office Productivity (Overall)). Benchmarks and scores are available on www.bapco.com. CPU should be 64 bit (emulated processors would not be acceptable) and working at designated CPU frequency by the CPU vendor. CPU must have at least three years warranty from the original CPU producer and this must be documented properly by the original CPU producer. Memory: DDR, minimum 1Gb RAM, maximum 4Gb Disk: 200 Gb disk space or more; ATA or SATA or SATA II; minimum 7200 rpm; minimum 8MB cache Graphics: minimum 256 Mb (not shared), supporting native resolution for 15 and 17 monitors, DVI port CD/DVD: DVD ROM + CD R/W (combo drive) Network: 10/100/1000 Mbit/s Fast Ethernet Network Card Sound: Integrated sound card Ports and interfaces: minimum: 6xUSB 2.0, 1xSerial, 1xPS/2 Mouse, 1xPS/2 Keyboard, 1xParalel, 1xVGA, 1xDVI-Out, 1x MIC audio, 1xLine out Audio, 1xRJ45 Mouse & Keyboard: 1xstandard mouse, 1xkeyboard Standard BarCode Reader: 1x (for reading bar codes printed in Health insurance card and patient identification and Professional staff identification) Monitor: LCD 15 supporting native resolution for 15 monitors Operating system: MS Windows XP Pro or other equivalent with similar functionalities; Software for rescue and recovery Warranty: 3 years minimum
Upgrade of (N)IHP telecommunication lines to access HDAC will be performed and agreed by MoH, (N)IHPs and Macedonian telecommunication providers it is not required from the provider in this tendering procedure.
4.8.3 Software solution for (N)IHP

Special software solution for (N)IHP should be based on Datawarehouse with strong Analytical and reporting tools (OLAP tools required) corresponding all NIHP and IHP needs. Datawarehouse must be placed at HDAC. Data for datawarehouse should be pulled automatically and periodically from transactional IHIS database and/or EHR/EPR database wherever possible. For special reports and data that could not be generated automatically and transferred to Datawarehouse, provider will have to develop special interfaces (web forms) for reporting for HCIs, IHPs or NIHP. Users from NIHP and IHP will use special Web or Client tools to access data in Datawarehouse according to user rights.
42
IHIS Specification
Version 1.2
Software solution, implemented by provider, must enable (N)IHP users to manage 10 most important registers in health protection field, about 40 statistical reports prepared periodically and some indicators which have to be sent to WHO. Mentioned registers, statistics and indicators will be presented to the provider after contract award. Those registers, reports, statistics and indicators are similar from country to country and are some kind of standard which is well known by providers who are specialized in eHealth area. That is why no further details are presented. At the beginning of the (N)IHP subsystem implementation, the provider will have to prepare detailed design of datawarehouse, tools, predetermined registers, reports, indicators and analysis in the cooperation with IHP and NIHP staff. Software must enable (N)IHP users to perform data consistency checking for all data and reports generated from HCIs and other institutions transactional data. Software must also enable users to prepare standard reports and analysis on gathered data in Datawarehouse, to cross data from registers and tables, to prepare adhoc analysis and reports. The solution will have to use central IHIS Datawarehouse. Web clients or other local clients (fat clients) for (N)IHP are allowed. Paper reporting and other kinds of reporting from HCIs and other institutions to (N)IHP will no longer be necessary, because provider will have to implement the solution where all needed data for (N)IHP will be generated automatically from transactional data in central IHIS database or gathered additionally through web reporting forms which also have to be developed by the provider. Detailed analysis and design of the (N)IHP subsystem should be prepared by awarded provider at the beginning of the (N)IHP subsystem implementation.
4.9 Management subsystem

Management subsystem will have to support functions for administering, managing and supervising whole IHIS system. It will have to monitor all IHIS subsystems and their usage. It will also have to provide special reports and statistics for management/contracting authority (e.g. user activity, number of patient visits per institution, number of beds occupied, number of prescriptions per doctor and other reports defined by the contracting authority). Awarded provider will have implement management system with next functionalities (some of them already described in chapter 4.3): user rights management (adding new users, defining user groups and their permissions, adding users to groups, defining/changing permissions, deleting/archiving users) user activity tracking and reporting (recording and tracking user activities, history of each user activity, reporting on user activity ) transaction tracking and reporting (e.g. number of transactions per institution and per user) administering and managing central registers and coding lists/tables (updating records in central registers and coding lists, importing/exporting data) recording and reporting on bad transactions, errors and telecommunication interruptions controlling status of data interface activity (e.g. checking status of last 10 data transfers between HDAC central database and HIF system)
43
IHIS Specification
Version 1.2
updating basic data about institutions (e.g. hospital description) and their services preparing and sending special messages to the users of IHIS subsystem (e.g. message to users on improved functionality for scheduling patient visits) special reports defined by supervising and contracting authority (e.g. user activity, number of patient visits per institution, number of beds occupied, number of prescriptions per doctor, institution efficiency and other reports defined by the contracting authority) ad-hoc reports other functionalities defined in the first phase of implementation to fully control and monitor IHIS from central location
4.10 eHealth portal

4.10.1 eHealth portal introduction
One-Stop-Shop eHealth Web Portal will be established where patients or professional staff will have access to general or public information and also personal and health data according to security schema. It is planned to establish few sub-portals, e.g. for doctors, for patients, for public, for reports/statistics. eHealth portal have to be implemented using strong Content Management System (CMS) which will enable MoH and other content managers total flexibility and control. CMS will have to support easy data updating and publishing, adding new content categories, adding new portlets and application segments (e.g. forum, survey, search bar, faq,), adding new links, adding multimedia content, changing look and feel of the page, traffic statistics. For public portal it is desirable to enable some of the most popular WEB 2.0 features. eHealth portal will be implemented according to the implementation plan at the end of the document.
4.10.2 Portal functionality

eHealth portal will consist of three sub-portals: for professionals, personal portal for patient, general public portal for general information. Portal for professionals will include information and services for professionals like: Access to subsystems and functionalities of IHIS subsystems On-Line help and user manuals for professional users FAQ Indicators and statistics related to health care Information about conferences and other educational events Information about new researches, studies and other knowledge from whole world in Health care field Public registers (e.g. drug register)
44
IHIS Specification
Version 1.2
Professional forums On-line consulting for public (e.g. answering on questions from citizens about specific illnesses) Other functionalities defined in the first phase of
Personal portal will give access to patient to extremely sensitive and confidential data. Therefore maximum security mechanisms must be implemented to protect unauthorized access (minimum HIPID card number to be used, user name and password which will have to be changed every month, https). Information available in personal portal: medical data (summary from EHR/EPR records) doctor appointments/scheduling waiting lists drug prescriptions preview personal data insurance status multimedia materials when available (e.g. ultrasound clips)
General public portal will be mainly focused on educating citizens to live more healthy life, to prevent from diseases, to eat healthy food. Also forums, expert articles and other public data will be available. It is required from the provider to implement portal, three sub-portals and interface for content management. Portal content management system will be mainly used by MoH and NIHP who will maintain the majority of data and information published in the general public part of portal and professional part of the portal. Access&Security to sub-portals: General portal will be accessible for general public without any login or password. For accessing personal portal or any personal information, strong security procedure and control must be implemented. (Minimum user name, password, and HIPID number, and HTTPS protocol is required). Access to the portal for professionals will be granted upon user name and password entry.
5 TESTING, TRAINING, PRODUCTION, DOCUMENTATION, USER SUPPORT

5.1 Testing requirements
MAINTENANCE,
All installed software, hardware and communication equipment should be tested before production. Provider will have to prepare and document testing scenarios and testing procedure (documenting errors, testing parameters, circumstances). All IHIS software solutions/subsystems must be tested in three phases:
2007 Ministry of health 45
IHIS Specification
Version 1.2
1. Testing in providers testing or development environment 2. Testing on IHIS testing infrastructure in HDAC 3. Testing on IHIS production environment before full roll out. Testing procedures should be managed by the provider. Beside the providers testing staff, also staff from MoH and other stakeholders should be included in testing procedures. Testing will have to follow next testing schedule (see diagram bellow) where all three phases are evident and also required testing procedures: unit testing, functional testing, performance testing, integration testing, stress testing, user testing, acceptance testing.
Testing procedures and scenarios must all be accomplished before going live into production.
5.2 Training requirements

It is required from the provider to train all users (see chapter 6). All users of IHIS system must be trained properly maximum 2 months before using the IHIS system and minimum 10 days before using the system. Provider must prepare user manuals for all users in Macedonian language and Cyrillic characters. Training rooms and equipment must be organized and ensured by the awarded provider. Training for system administrators and other special users (e.g. HDAC staff, HIF users) must be organized separately and detailed knowledge and practice must be provided. Additional trainings in case of functionality changes or in case of new users will be provided during maintenance period. See Chapter 6 for number of users to be trained.
5.3 Maintenance requirements and user support

IHIS implementation is divided into phases. After each phase it is required from provider (further also contractor) to ensure basic maintenance and user support which should be estimated by the provider and presented in the offer. Price for maintenance and user support should be presented
46
IHIS Specification
Version 1.2
separately. Maintenance and user support starts at the end of first IHIS implementation phase and ends 3 years after last IHIS implementation phase finished. While communicating with the contractor and ordering of activities, the public authority will use the terms basic maintenance (or just maintenance) and the term supplementary maintenance and upgrades. Here is described the definition of terms as understood by the public authority.
Basic maintenance contains (should be included in maintenance and user support price): management and coordination of activities between the contractor and the public authority or end users; keeping track of technological trends, associated with information solution and preparation of suggested measures for uninterrupted operation and for improvement of functioning that will be implemented by the contractor within the framework of supplementary maintenance; Regular hardware maintenance that was installed by the provider Bug Fix Releases and Remedial Software Patches in compliance with manufacturers instructions; keeping up-to-date (reconciliation with regulations); managing security system (protection system, backup system); due to the changes of regulations by directions of the contracting authority within the framework of monthly maintenance fee; basic remote user help and consulting on the use of information system described further; additional education of users in case of larger changes in functionalities; availability and readiness of the contractor to confer with the public authority about planning and ensuring proper resources that are (as necessary) in agreement with the public authority used for updating, changing or upgrading of information solution with new modules by additional orders and as per agreement with the contracting authority; preparing plans for updating, changing or upgrading IHIS documenting activities, agreements and changes with reference to the basic maintenance of information solution additional trainings for existent users in case of functionality changes in the system; additional training for news users of the system up to 100 new users/year Constant education of contracting authority people and administrators for providing basic maintenance smaller software upgrades up to 5 programming days per month other maintenance activities ordered by the contracting authority that do not exceed 2 programming days per month ensuring 99,8% availability of all IHIS functionalities implemented according to the implementation plan
47
IHIS Specification
Version 1.2
Handling incidents: Types of incidents or problems during maintenance: q Critical incident application is not working, system in not working or cant be accessed Serious incident application or system is working but its very slow or some functions are not working as usual or as planned, it is difficult to use the application Minor incident doesnt affect functionality essentially Design or Look&Feel incident does not affect any functionality, just some wishes for better user experience
q q -
Provider has to open telephone line and e-mail channel for receiving incident reports from users Incident response time is a time that passes from the time incident is being reported to the time when provider started solving the incident. Response times and solving incidents
Incident Type Critical incident Serious incident Minor incident Design or Look&Feel incident
Response Time 15 minutes 1 hour 12 hours 48 hours
Time to solve the incident 1 hour or to be agreed with contracting authority depending on incident complexity 4 hours or to be agreed with contracting authority depending on incident complexity As soon as possible, after all critical and serious incidents are solved 10 days or as soon as possible, after all critical, serious and minor incidents are solved
Basic remote user help included in basic maintenance requirements: 24/7 users support for all user groups which will be included in the IHIS according to implementation plan Answering to user questions about IHIS functionality, processes, user rights and other issues Set up a central database for recording and tracking incidents, questions and answers to users. Answering to user questions in Macedonian language Constant educating of contracting authority people to be able to handle basic remote help on their own
48
IHIS Specification
Version 1.2
Informing users about planned changes in software or maintenance that will affect the usage of software (e.g. specific functionality will not work 1 hour)
Supplementary maintenance and upgrades contains (for supplementary maintenance and user support additional agreements and payments are planned no supplementary maintenance and upgrades should be provided without preliminary agreement with contracting authority): maintenance activities that exceed basic maintenance; information solution upgrade by the order and as per agreement with the contracting authority; control monitoring of information solution operation in agreement with the public authority; improving and adding functionalities, remedy of non-essential errors on request of the public authority; performance improvement based on suggestions of the contractor or the public authority and performed on request of the public authority; information solution adjustment according to changes of licensed software environment where information solution operates, within the framework of possibilities and assurances of principals environment producers; user support and consulting on location of the public authority as per agreement with the contracting authority; installing new version or installing of changes and updates of information solution, installing on a new location on request of the public authority; documenting activities, agreements and changes regarding supplementary maintenance of information solution.
5.4 Documentation
Documentation required from the awarded provider during project implementation: Document describing and presenting project plan in details (phases, activities, deadlines, deliveries, milestones, roles). Project plan have to be prepared at the beginning of the project after the contract is signed. Project plan will be consolidated with contracting authority. Project plan must clearly indicate deadlines for all deliverables, documents (described further), testing, training, production. Detailed analysis and software solution design for each phase of implementation and for each subsystem (prepared in the beginning of each IHIS implementation phase or subsystem) Document describing general (information) and technical architecture of the system. Document describing software interfaces and standards
49
IHIS Specification
Version 1.2
Testing scenarios and testing results (prepared in the beginning of each IHIS implementation phase) All software technical documentation and user manuals All hardware technical documentation set up by the awarded provider Manuals for system administrators including all procedures for managing IHIS (e.g. archiving and restoring, user rights management) Manuals for end users
The list of documentation could be supplemented by contracting authority at the beginning of the first phase of implementation. Complete documentation should be delivered to contracting authority on CD or DVD media and on paper form after each IHIS implementation phase (see chapter 8).
6 IHIS & HDAC COMPLEXITY MEASURES

For better understanding of the complexity of the IHIS system and for better costs estimation for maintenance and user support, MoH is presenting several representative numbers to give clearer picture of IHIS complexity: Hospital beds (year 2005): 9575 beds Health care workers with university level of qualification - total (year 2005): 5759 q 4392 physicians out of total: 3052 specialists out of total number 706 dentists out of total number 205 pharmacists out of total number Nurses with higher education (2005): 349 Nurses with mid qualification level (2005): 5348 Num. of general hospitals (2005): 16 Clinics and institutes (2005): 21 Num. of Specialized hospitals and rehabilitation centers (2005): 16 Num of Non-hospital dispensaries (2005): 10 Patients admitted in hospitals in 2005: 211978 total General practitioners (2005): 486 organizational units Specialized departments (2005): 435 organizational units Total No. of visits to physicians (primary health care): q q General practitioner (2005): 3993141 Specialized department (2005): 2831315
50
IHIS Specification
Version 1.2
Number of IHPs: 10 Number of HIF regional units: 30 + 1 central Number of insured people in Macedonia (2005): 1898334
7 SCALABILITY, FUTURE IHIS UPGRADES

IHIS must be open to further upgrades, adjustments and technical improvements. Certain level of scalability is required regarding: increasing number of user increasing number of patients and institutions connected to the IHIS adding new modules and subsystem using same or other database adding and customizing data interchange formats, protocols and schemas adding new servers and database resources (new hardware, new hard drives) upgrading Identification subsystem Patient Health ID & Insurance card, Professional ID Health card to the next level of sophistication where SmartCards and digital certificates will be implemented adding functionalities for digital signatures where needed
Planned functionality upgrades for near future (not a part of IHIS implementation plan presented in this document): DRG implementation Mobile applications and other mobile devices used by general public of professionals Personal portals with telemedicine functionalities
8 PROJECT IMPLEMENTATION PLAN

8.1 Implementation phases, deliverables and time schedule (delivery plan)
Further table is showing IHIS implementation phases. For each phase it is described which subsystems must be implemented, for which institutions, and what are other tasks or activities to be performed (e.g. maintenance) by the provider. Last column is presenting deadline for phase implementation agreed by MoH and Working Group of ICT system in Health Care. Each Phase must consist of two mayor steps: 1. Development:
51
IHIS Specification
Version 1.2
a. Gathering detailed information, detailed analysis and solution design. First step should provide answers like: which standard to use, which data to implement in central database, what user requirement must be implemented, which central register and coding tables should be used in single phase, which functionalities to use and which should be adjusted or developed, which implementation method to use and similar questions. b. Adjusting offered solution to satisfy requirements, development, testing (provider must prepare testing plans for each phase; plans should be discussed with MoH and other stakeholders). After detailed analysis and design the provider should adjust offered solution to correspond to user requirements and decisions made in first step. The adjustments required by the Macedonian legislation and application scenarios for Health Provider Institutions needs, must be included in the price. 2. Implementation: a. Training. Training must be provided for all users of new system and administrators. Provider must organize efficient training for users to be able to take full advantage of new system. b. Putting solutions in the production After second step maintenance, help desk and upgrading should be performed by the provider as described in chapter 5.3.
Phase No.
Subsystems modules to implemented
or Institutions to be Other tasks be included, number activities to of institutions performed
or Deadline be
June 2008
Phase No.1
- Implemented subsystem: HDAC center (HW, SW, Telecomunication Equipment) in location provided by MoH (NO backup location in this Phase!). Chapter: 4.3
- Setup all central registers and coding tables in HDAC central database, data migration - backup unit and backup solution (HW, SW, processes) for HDAC must be provided in first phase
- Developed subsystem: Patient Health ID & Insurance card, Professional ID Health Card. Chapter: 4.4. - Developed subsystem: HCI subsystem including EPR/EHR data, Chapter: 4.5. Not including Financial, accountancy, and administrative solution - Developed subsystems: HIF subsystem, Pharmacy subsystem, (N)IHP subsystem - Developed subsystem: eHealth portal, Chapter: 4.10
All subsystems must be developed and tested
December 2008
52
IHIS Specification
Version 1.2
- Developed subsystem: Management subsystem, Chapter: 4.9 - Implemented subsystems: HCI subsystem including EPR/EHR data (without FAAS); Health ID & Insurance card Professional ID Health Card subsystem; HIF subsystem; Pharmacy subsystem; (N)IHP subsystem PILOT IMPLEMENTATION for 5 Health homes, 2 Pharmacies, 2 Hospitals, 2 regional IHP, 1 NIHP, 1 HIF !! - Implemented subsystem: eHealth portal, including basic data available at this phase of IHIS implementation. Chapter: 4.10 Implemented subsystem: Management subsystem, for subsystems, users and data available at this phase of IHIS implementation. Chapter: 4.9 - maintenance, help desk and upgrading April 2009
Phase No.2
- Upgraded & Implemented subsystems: HCI subsystem including EPR/EHR data (without FAAS), Health ID & Insurance card Professional ID Health Card subsystem, HIF subsystem, Pharmacy 2 subsystem, (N)IHP subsystem for all Health 3 homes, all Pharmacies, all Hospitals, 10 regional IHPs, 1 NIHP, 1 HIF !! - Upgraded & Implemented subsystem: HCI subsystem including EPR/EHR data, Chapter: 4.5. Financial, accountancy, and administrative solution !! - Upgraded & implemented subsystem: eHealth portal, including all data available at this phase of IHIS implementation. Chapter: 4.10 Upgraded & implemented subsystem: Management subsystem, for all subsystems, users and data available at this phase of IHIS implementation. Chapter: 4.9
Implemented Datawarehouse
December 2009
- maintenance, help desk and upgrading
Phase No.3
Maintenance user support and
- Upgrade and implement IHIS with HDAC backup location backup data center!! - Chapter: 4.3 Maintenance and user support
- maintenance, help desk and upgrading Maintenance support and user
April 2010
April 2010 + 3 years
2
3
See chapter 6 for details about number of institutions and professional staff See chapter 6 for details about number of institutions and professional staff
53
IHIS Specification
Version 1.2
9 SELECTION CRITERIA - QUALIFICATIONS, MEASURES

QUALIFICATIONS: 1. Already implemented and currently running health care information systems, where cumulative number of citizens (patients) in databases is more than 1.500.000, or cumulative number of professional health care users is more than 2.000 at the moment evidence: described references and confirmed by the referencing contracting authorities (the bidder must describe each reference, for each reference number of citizens currently in the database and number of health care professionals using the system must be evident, for each described system the year of implementation should be evident) 2. 1 reference implementation of health information system using HL7 in last 5 years evidence: described reference and confirmed by the referencing contracting authority. 3. 2 reference implementations in last 5 years of datacenters similar to the size and complexity needed for IHIS HDAC - evidence: described reference and confirmed by the referencing contracting authority (The bidder must describe equipment, installation process total price, year of implementation). a. Datacenter implementation means supply and installation of hardware, software and telecommunication equipment to be fully operational b. Similar Datacenter means data center where total price for equipment supply and installation was 1.000.000 EUR or more 4. 3 reference implementations of web based software solutions for more than 2000 enterprise end users (public web sites do not count) - evidence: described reference and confirmed by the referencing contracting authority (the bidder must describe the solution and number of users). 5. Official certificates for software developers related to offered development platform or programming language. At least one half (1/2) of developers, proposed for this project, must possess certificate for developing in offered software platform or programming platform - evidence: copies of certificates for people presented by the bidder. 6. Official certificates for system engineers and administrators corresponding to offered hardware and telecommunication equipment for HDAC. At least one certificate for each piece of offered hardware and telecommunication equipment must be presented if exists evidence: copies of certificates for people presented by the bidder. 7. The Bidder must present a list of persons planed to be involved in the project evidence: list of persons + CV for each person. From the list it must be evident (Name, Surname, Education, Years within the company, proposed role in the project). From the CV it must be evident: a. Name, Surname b. Birth date c. Education
54
IHIS Specification
Version 1.2
d. Company e. Year of professional experience f. Years of professional experience in the firm
g. Role in the project (e.g. project manager, architect, designer, programmer, tester, system engineer, system administrator) h. Certificates i. List of projects in last 5 years
8. The bidder must present at lest 20 people for this project and their roles 9. Company or companies must present in total (jointly) evidence: official statement: a. yearly turnover greater than 5.000.000 EUR b. more than 100 employed
EACH COMPETING PROVIDER MUST INCLUDE NEXT DOCUMENTS IN THE OFFER: 1. Detailed description of offered system already used by other customers. It is required from the provider to describe in detail (technology, functionalities, procedure, integrations,) each subsystem from technical specifications. It must be clearly evident which required functionalities are already developed and which are not developer or are in the phase of development. 2. Detailed description of adjustments or developments that should be made in offered system to fulfill all requirements of IHIS described in this document. 3. Detailed description of hardware, communication equipment and system software for Health Data&Application center HDAC, proposed by provider according to the requirements. 4. Detailed description of implementation phases, described in chapter 8.1, as seen by the provider. Each phase should be described in a way that it will be clear what activities are planned and what is expected from contracting authority and other stakeholders in Macedonia to provide or to contribute. 5. Detailed time schedule for implementation phases a. Each implementation phase should have more tasks. b. Each implementation task should have deadline and clear deliverable or result. 6. Detailed description of user trainings 7. Detailed description of basic maintenance services and user support services 8. List of all references of the company or companies in the field of Health care information systems. 9. Total price for each implementation phase according to planed and described activities and results. Price for maintenance and user support should be presented
55
IHIS Specification
Version 1.2
separately in the offer. Maintenance starts after finished phase No.1 and finishes 3 years after finished last phase of implementation.
MEASURES: 1. Cumulative costs for all implementation phases (lower price higher score) 2. Cumulative costs for maintenance and user support (lower price higher score). Maintenance and user support starts at the end of the first IHIS implementation phase and ends 3 years after last IHIS implementation phase accomplished. 3. Number of central health information systems implemented with central EHR database and central hosted software, without local databases and applications on the side of health care providers all web based user interfaces (+points) 4. Offered solution is using SOA architecture (+points) 5. Offered solution is using HISA (+points)
56
IHIS Specification
Version 1.2
10 DOCUMENTS AND SOURCES

[1] Terms of Reference; Consultancy for Drafting the Technical Specifications For Health Information System [2] Strategy for the Development of Macedonian Integrated Health Information System; Final Draft [3] Information from the conducted survey of the current condiditons with ICT resources in healtcare institutions in the republic of Macedonia [4] Tender specification for basic information system in Health Center Skopje [5] Tendeskata dokuemntacija za izgotvuvawe ili nadgraduvawe na softverski aplikacii za potrebite na Republi~kiot zavod za zdravstvena za{tita i 10 Zavodi za zdravstvena za{tita [6] Interviews with institutions (MoH, MoISoc, HCIs, UCCS, WG, PCU, IHP, NIHP) [7] Verification of current situation analysis in HCIs and functional analysis AND Concept and General Network Architecture for IHIS of the Republic of Macedonia, august 2007
57

Suplemented Version of IHIS Specifications PDF

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Suplemented Version of IHIS Specifications PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Ministry of Health of the Republic of Macedonia Health Sector Management Project Project Coordination Unit

ICT REPORT (Contract activity C)

Version 0.1 Draft 0.2 Draft 0.3 Draft 0.4 Draft

Last Change 12.09.2007 14.09.2007 25.09.2007 01.10.2007 05.10.2007

1.1 Final 1.2 Final

Confidentiality: According to PCU and project procedures

2007 Ministry of health

2007 Ministry of health

4.4.1 4.4.2 4.5

4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.6

4.6.1 4.6.2 4.6.3 4.7

4.7.1 4.7.2 4.7.3 4.8

4.8.1 4.8.2 4.8.3 4.9 4.10

2007 Ministry of health

SELECTION CRITERIA - QUALIFICATIONS, MEASURES ......................................54 Documents and sources .......................................................................................57

2007 Ministry of health

1.2 Document purpose

2007 Ministry of health

2007 Ministry of health

2.2 Project scope

2.3 Project objectives

Long term objectives:

2007 Ministry of health

User representatives group

2007 Ministry of health

2007 Ministry of health

Program Steering Committee Advisory Board IT, Medical, Legal,

Group Program Manager Technical Program Manager

User Representatives Group

Project Office &Technical support

Contracting authority project group

Provider Project Manager

Contracting authority project group

Provider Project Manager

Provider Project Group

Provider Project Group

2007 Ministry of health

3 CURRENT STATE OF HEALTH IS IN THE REPUBLIC OF MACEDONIA

3.2 Key findings

2007 Ministry of health

3.3 Current state in Health related institutions in Macedonia

2007 Ministry of health

3.4 Starting point for future IHIS

2007 Ministry of health

4 FUTURE IHIS SPECIFICATIONS

2007 Ministry of health

4.2 General IHIS use case and process description

2007 Ministry of health

4.3 Health Data & Application Center HDAC

2007 Ministry of health

4.3.3 System Software, servers software and licenses

2007 Ministry of health

4.3.4 Central IHIS1 software, database and interfaces

Integrated Health Information System

2007 Ministry of health

4.3.5 Common Health and other registers, coding tables

2007 Ministry of health

2007 Ministry of health

4.3.7 Security and User rights management

4.3.8 User activity tracking User & activity LOG files

2007 Ministry of health

4.3.10 System backup & Disaster recovery