ICP's and EHR

An ICP determines locally agreed, multidisciplinary practice based on guidelines and evidence where available, for a specific patient/client group. It forms all or part of the clinical record, documents the care given and facilitates the evaluation of outcomes for continuous quality improvement".

National Pathway Association (1998)

ICP’s have their origin in providing coordinated care to patients by different specialist teams within a healthcare organisation. Each team records their interventions on a patient for a specific health condition in the organisation’s Electronic Patient Record (EPR) system and other teams intervene accordingly based on the notes provided. This paved the way to define electronic ICP’s (e-ICP) in EPR systems.

The advent of Electronic Health Records (EHR) brought the possibility of extending ICP’s across multiple healthcare organisations from different care settings. EHR's facilitate flow of information across different care setting boundaries even to agencies outside healthcare (e.g. social care) who are involved in the care of a patient.

Benefits of Electronic Care Pathways over EHR's:

• Allows care pathways to be built around patients and not institutions by providing real time recording and allowing different organisations involved in the patient care to have the same view
• e-ICP’s provide quick access to information(instead of browsing though bundles of paper for which each organisation has different format and different recording styles) and provide multiple views – high level summary view from different organisations as well as detailed view of each organisation in a chronological fashion
• e-ICP’s allow faster remodelling and review of business processes to suite each patient

However the difficulties in deploying e-ICPS’ through EHR is not a technological one but cultural and business one involving the need for agreeing common data formats and sharing the data owned by an organisation across different care settings and agencies.

The Transit Electronic Health Record

Electronic Health Record is normally seen as repository of aggregate clinical and demographic information fed by point of source systems from different care settings. But the infrastructures associated with the EHR are being used to perform other ancillary functions such as facilitating the data exchange between the different point of the source systems. A classic example is the exchange of patient data between two systems through a project called GP2GP as a part of the UK CFH-Connecting for Health initiative.

The objective of GP2GP record transfer mechanism is to support the exchange of a GP’s (General Practitioner who is the patient primary care service provider in the context of UK) patient record electronically to a new practice when a patient registers with a new GP. In England an estimated 10% of patients change their practice each year and if the average list size of a practice is 1500 then there will be average of 150 transfers each year per practice. Most practices handle this transfer using the standard Lloyd George envelope or Medical Record envelope method for the transfer of the patient’s past care paper record.

The most common process of transfer of the electronic component of the patient record using Lloyd George envelope method is to produce a printout of the content of the medical record and to put it in the Lloyd George MRE at de-registration. Factually few doctors study such printouts and fewer practices re-enter any salient information and this information is unavailable to assist future care. Thus, an effective method which is aimed at the increased use of electronic records by GPs to improve the care of the patients is reducing the data quality of the patient record when passed to other GPs.

Currently England under CFH with history of pilot implementation of GP2GP using HL7 V3.0 by HIRI (Health Informatics Research International Ltd) consortium in 2003 is now trying to provide this transfer electronically using the national infrastructure and methodology developed under the National Programme for IT-CFH. The GP2GP messages, designed form part of the CFH Message Implementation Manual to support an automated request, acknowledgement and send of the electronic component of the record to assist in the continuation quality electronic records when a patient moves practice.

The objectives and benefits of GP2GP as per CFH website (http://www.connectingforhealth.nhs.uk/systemsandservices/gpsupport/gp2gp) are twofold – benefits the patients and benefits to the practice administration. The benefits of using GP2GP to the patients as perceived under GP2GP are

Ø The patient health record being available to the new GP a lot sooner (e.g. within 24 hours)

Ø The new GP will have knowledge of the patient’s:
o Current medication
o Drug interactions
o Current problems
o Key past medical history
o An improvement in patient safety

Ø Increase patient confidence that they will get good continuing care

Ø Prevent patients being asked information that they have previously reported

The benefits to the practice administrative support teams as perceived under GP2GP are

Ø Reduction in administrative time at the previous GP practice to find and forward on patient records to the new GP practice

Ø Reduction in administrative and clinical time at the new GP practice to review and summarize or re-key the patient record received from the previous GP practice

Ø Reduction in the time taken for the practice to receive the patient record

Ø Reduction in administrative time to chase up patient records from Health Authorities

Exchange Mechanism under CFH GP2GP

The GP2GP process under CFH starts with the registration of a new patient with a GP practice. The GP2GP explicit flows are triggered by the NHAIS Registration links acceptance message flow and the update of the GP registration on a national MPI database called PDS (Personal Demographic Services) which is a part of the national EHR called Spine.

The GP2GP process covers the electronic transfer of the patient record between primary care systems through the MHS (Message Handling Service) of the Spine supplied by the NHS Care Record (NCRS) National Application Service Provider (NASP). There is no interaction with the on-going paper process of transferring Lloyd George envelopes.

The Expected basic functionality provided as part of GP2GP by CFH is as follows

Ø Construct and process EHR Request & Acknowledgement messages
Ø Construct and transfer EHR Extract and integrate into receiving system

Figure below the GP Exchange under CFH GP2GP when a patient shifts from Practice A to Practice B. The exchange is based on intermediary ebXML exchange where the infrastructure of the national EHR called Spine is used as the intermediary MHS.

A1- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration

A2- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration

A3- As part of the local registration process, the PDS is queried for the patient’s up to date details e.g. demographics, NHS number and current registration details

A4-The Spine Integration infrastructure will route the query to PDS which will populate a response message with the available patient details. If no record of the patient exists on PDS then a new entry will be created and appropriate PDS update messages sent

A5- The patient demographics and NHS number content of the PDS query response is integrated in the local system.

A6- The GP system will interrogate a national directory called SDS to find out if the practice system with which the patient was previously registered is compliant for GP2GP record transfer messages. The SDS keeps a list of all compliant systems.

A7-If the SDS response is negative e.g. the practice system is unable to send/receive GP2GP record transfer messages then the GP system will alert the user to the fact that no electronic transfer of the existing patient record is available

A8- A positive SDS response will trigger a record transfer request to be sent to Spine to route it to the GP practice system.

A9 - The Spine will route it to the GP practice system with which the patient was previously registered

A10- GP system will receive the request and alert appropriate users to the request.

A11- The EHR Request will be considered by the requested GP Practice

A12- The GP system will send an acknowledgement of receipt of the request to the spine which acts as intermediary to be sent to the requesting GP system.

A13- The Spine will forward the acknowledgement of receipt of the request to the requesting GP system.

A14- The GP system will receive the acknowledgement.

A15- The GP system will alert appropriate users to the receipt of the acknowledgement.

A16- If the request can be fulfilled the GP system will send the patient’s Primary care record as an EHR extract message to the Spine

A17- The Spine will forward the EHR extract to the requesting system by acting as intermediary.

A18- The GP system will receive an EHR extract

A19- The GP system will notify appropriate users to the receipt of EHR extract

A20- The EHR extract will be considered by the requested GP Practice

A21- The EHR extract will be integrated with the appropriate patients record

PS: Iam not sure why they are called EHR messages though but again everyone have their own definitions

EHR and Open Source Software

One of the major obstacles in deploying Electronic Health Records (EHR) apart from the usual political and technical reasons is the huge outrageous economic costs associated with the product suites involved in the deployment of EHR. So one option to reduce the costs might be looking at using Open Source software (OSS) to improve the financial viability of the implementations. Gartner has predicted that

· By 2010, 90 percent of Global 2000 organizations will have formal open-source acquisition and management strategies.
· By 2008, OSS solutions will directly compete with closed-source products in all software infrastructure markets.
· By 2010, open source will be included in mission-critical software portfolios within 75 percent of Global 2000 enterprises.
· By 2010, Global 2000 IT organizations will consider open-source products in 80 percent of their infrastructure-focused software investments and 25 percent of business software investments

In this post I will look at the main features of Electronic Health Records and the commercial software available for implementing these features and the open source alternatives for them. At a high level the features of Electronic Health Records are

Patient / Person Registries

One of the important feature required for the successful implementation of a EHR is the establishment of a patient/person registry and the identifies associated with them. This will allow the correct identification of patient’s identification and subsequent association of care records with them. The issues associated with the establishment of such a registry are

• Management of local identifiers and national identifiers
• Migration of data; resolution of duplicates and confusions
• Synchronization mechanism between local and national records

The commercial software for the establishment of registry are
• SUN SeeBeyond eView
• QuadraMed EMPI Solutions
• Initiate Identity Hub™ software
• The MPI software associated with Product Vendors such as IDX, Cerner, Eclipsys, McKesson,

The alternative OSS for the registry are
• Record Locator Service (RLS) – openhre
• Part of Medsphere OpenVista
• Eclipse OHF - Patient Identifier Cross-Referencing (PIX)
• High Available Open Source Database Solution using MySQL for Enterprise Registry Application with advance features.

Exchange of HealthCare data –Application Interoperability

One of the major features of EHR is the ability to feed a central health repository healthcare data associated with key events and at the same time exchange the data with different clinical systems. The issues associated with exchange of clinical data are

• Level and Granularity of clinical data
• Quality of data and existing data
• Choosing the right standards
• Legacy Systems Compliance

The commercial software available for the exchange of clinical data are
• Sun SeeBeyond e*Gate
• Oracle HTB
• ORION Rhapsody
• Microsoft BizTalk
• IBM Websphere

The alternative OSS available for exchange of clinical data are
• Mirth
• Eclipse OHF Bridge
• JBOSS, Hibernate, Web Services,
• Enterprise Service Bus, Messaging

Appointment Bookings

Though Appointment bookings are not itself a part of the EHR the ability to provide options to referrals and allow appointments to be made between different care settings by clinicians and even by patients themselves is emerging as the part of different nation’s healthcare IT infrastructure. The issues associated with appointment bookings are

• Problems with departmental system slots
• Definition of Resources
• Category of appointments –Inpatient/Outpatient

The commercial software available for providing appointment bookings are

• Cerner Enterprise Wide Scheduling
• USA RMS
• Isoft Revive
• Scheduling.com
• Epic Cadence Scheduling

The alternative OSS available for appointment bookings are
• O3-MARIS
• OpenVistA Scheduling

Healthcare Portal

Healthcare Portals are a crucial component in the infrastructure of EHR not only from the perspective of content management of the data that can be made available to clinicians available in the repositories associated with EHR but also access to services like appointment booking which is a part of the EHR. The issues associated with Healthcare portals are

• Security controls for data visible to citizens over Internet
• Clinically safe to use with relevant data made visible

The commercial software available for building of Healthcare Portals are
• McKesson Physician Portal
• ORION Concerto™ Medical Applications Portal

The alternative OSS available for Healthcare Portals are
• iPath - Open Source Telemedicine Platform
• Liferay Portal Enterprise and Professional
• Akaza OpenClinica
• Integrated Portal and Enterprise Content Management system (Alfresco/OpenCMS/
Mambo/cocoon)

Information Governance – Access Control

Another crucial aspect in the management of portals is the management of access and the provision of role based access. The issues associated with access control are

• Definition of RBAC Activities
• Smart Card access for operators and normal for citizens
• Agreed definition of roles

The commercial software available for providing access based control are

• SUN LDAP
• Microsoft Active Directory

The alternative OSS available for access based control are
• Centralized Authentication & Authorization using Open LDAP

Reporting

One of the main outputs of EHR is the ability to generate reports and provide the ability to allow clinical and administrative governance. The issues associated with reporting are

• Lack of transparency of system schemas to reporters
• Lack of LDMs for operational / departmental systems, data warehouses
• Lack of data pedigrees for reported data elements
• Lack of comprehensive data dictionaries for systems

The commercial software available for providing reporting are
• Informatica
• Business Objects

The alternative OSS available for reporting are
• Jasper Suite

Brazil NHCP

I have been too pre-occupied with my work to do some quality blogging; I have not written anything till now about my favorite topic – Electronic Health Records. This is first of serious of blogs on various EHR initiatives around the world.Most of the information that will be included is public information and my intention is to simplify the information about the implementation from what i understand while allowing the users also to examine the contrast in the patterns used by different implementations. I have been told that Brazil is one of the first countries to have a successful implementation of Nation Wide Electronic Health Records. The project was termed NHCP – National Health Card Project. This project began as early as 1999 and a clinical pilot began in 2001

Aim of NHCP

The project was started to create national patient identification and information system for the Brazilian Unique Healthcare System called SUS -- Sistema Único de Saúde. Its aim is to collect patient treatment information in a national repository of clinical data.


Architecture Principles and Components

Figure below shows the logical architecture of the project. NHCP System is divided into 5 hierarchical levels, from the bottom: Point of Care Level, Municipal Level, Concentrator Level, State Level and Federal Level. The top three levels of the system has Permanent IP based network and the lower two levels has Dial Up Network as shown in Figure below.

NHCP Project has five major components

Ø Telecommunication infrastructure
Ø Point of care terminals;
Ø Servers and database facilities
Ø Point of care terminal and servers software
Ø Security issues and national standards to represent transmit and store health information.

The architecture of the NHCP is centered on patient and users having health cards. The health cards adopted in the project are used only for IDENTIFICATION purposes of users and health professionals and not to store clinical data. Both the users’ and health professionals’ cards have embossed the unique identification number, name, date, city and state of residence. The point of care equipment specially developed for this project has the card reader. The access to the system is limited to health professionals authenticated by the card and password. All data captured at the point of care is stored in the servers at the municipal, state and federal level

The technologies that were used are based on Java technology and the XML data format. The Java framework is based on the following concepts

Ø The NHCP is XML message-based; all communication between machines is XML over HTTP.
Ø Every server node can send and receive XML messages to and from any another server node.
Ø XML messages are associated to Java business classes.
Ø All XML data is handled dynamically using Java Reflection.

All XML is validated according to a rigid specification (DTD, infrastructure, and domain), which provides the flexibility necessary to add or remove business classes, and to modify the XML validation rules. In addition, servers and clients must authenticate to a server node using digital certification. The figure below depicts a generic server node with its principal building blocks and data flows.

Standards and Data Sets

The transport protocol used is HTTPS (HTTP +SSL). The terminals of care and municipal servers communicate using XML. The specifications were not HL7 but specifications agreed between Ministry of Health and the providers contracted for the development of the project. Document Type Definition (DTD) has been used for specifications.

The essential encounter data set contains the following information

Ø Reason for the encounter
Ø Diagnosis
Ø Procedures Performed
Ø Patient’s work-out
Ø Medication
Ø Follow Up

The diagnosis information is entered using ICD-10

Informational Governance

The use of the database of the National Health Card aims to only the management of health services by the different spheres of government and was guaranteed not to be used for commercial purposes or for any reason which hinders with constitutional rights of the Brazilian citizens. The architecture incorporates a Information Governance policy covering five basic requirements: privacy, authenticity, integrity, access control and audit of health data tied to the National Health Card.

For authentication any addition or alteration of information in the system is linked to an operator duly registered both for operation of the server and the terminal. All the health professionals responsible for the entry of data to the system are authenticated using health professional card which contains a encrypted password on the card.For access control, the system allows the implementation of a policy of setting privileges of access to classes of operators and standards of disclosure. All attempts to access information and functions of the system are stored for auditing purposes.

From IG point of view the systems offline are treated the same way as that of online systems. The traffic between a terminal and a server, upload between servers or service is performed on the HTTPS protocol, or HTTP protocol (Hypertext Transfer Protocol) protocol on the SSL (Secure Sockets Layer).

Scalability

Since spring 2003, the pilot infrastructure has been fully operational, consisting of:

Ø 8 million patient ID health cards
Ø 50,000 professional ID cards
Ø 3200 point-of care-clients
Ø 2 federal servers
Ø 27 state servers
Ø 13 concentrator servers
Ø 44 municipal servers

In parallel with the pilot project and in anticipation of consolidation for the rest of the country, 80 million people have been uniquely identified in the NHCP database, representing 40% of the Brazilian population. Interoperability with external systems is also operational. Systems from external vendors are communicating with the NHCP by exchanging XML documents.

NHCP server -side data:

Ø 180 different use-cases
Ø 1,800 Java classes
Ø 230,000 lines of code
Ø 700 different database tables
Ø 160 different XML message types
Ø 50 gigabytes of data/million users/year

Advantages

NHCP allows data to be queries and profiled; for example diagram below shows actual data queried from the NHCP system for San Jose dos Campos, a city of 500,000 people near Sao Paulo. The x axis shows the treatment procedures codes, the y axis the date, and the vertical z axis shows the corresponding quantity. So what happened to cause this peak? From the data, it was possible to identify that the peak was due to the annual influenza immunization program; it was in winter, and over a two-week period, nearly 5000 people got their influenza shots.

My Observations

The project is simple implementation but strictly not a EHR implementation per-se and looks more of a data ware house implementation. There were claims that the message specifications were done after debate with clinicans who were the main users. It did not follow any reference model based specs so any of the changes to the specifications to keep in line with advances with clinical terminology and data will be adhoc. Also usage of ICD10 will limit the amount of data collected considering that its mostly disease based. The data sets indicate minimal information is captured and also a mechanism to retrieve from central repository to point of care systems is not well defined. The integration mechanism looks like a hardcore java implementation and non-implementation of a standard middle ware implementation will have its own technological refresh problems and scalability problems. Also some of the technologies used like DTD , XML binding has since become rarely used with the advent of XSD , SOAP , JAXB etc as the artcile on the SUN website indicates.

But the framework on the whole is a good start but building on the top of it may be bit difficult and any extensions to it may look out of place considering the usage of HL7V3.0 , SNOMED have become more wide-spread now.

Links, References, Acknowledgements and Copyright

http://java.sun.com/developer/technicalArticles/xml/brazil/

Lemos M, Leao de Faria B. The Brazilian national health card project. Proceedings of the International Nursing Informatics Conference. Rio de Janeiro; June 2003.

http://dtr2001.saude.gov.br/cartao/ - Official Site with detailed info

EHR White Paper

Nation and Region Wide Electronic Health Records are currently deployed or are being deployed in several countries around the world to enable sharing of care records within an organization and between different organizations. This sharing of health records would enable the patient's medical history and other details to be available at the point of care and would enable effective treatment of patients. This is further discussed in a paper which was published on TCS web site where i work in which the need for Electronic Health Records (EHR) andthe key design principles for EHR are described.


The link for the white paper is at

http://www.tcs.com/SiteCollectionDocuments/White%20Papers/TCS_WP_NatHealth.pdf

EHR and SOA

It has been some time before i posted anything new. A combination of lethargy and work pressure sucked me away. But something caught my eye which i thought is worth commenting on.

A lot of RFP's these days quote SOA as the preferred architectural pattern. Well it sounds reasonable considering the fact that

Ø Legacy applications/existing systems can be refined to support EHR without the need to make the supporting hospitals introduce new applications as is seen by in case of one national programme which is delayed.

Ø Support for new range of transactions/workflows by enabling orchestration of services in local application and EHR.

Ø Enables faster delivery and deployment of different components of the solution using off- the- shelf solutions.


SOA enables easy separation of EHR and local applications and at the same time the services exposed by applications within local and the EHR settings will be interoperable for the entire infrastructure to be perceived as single system. The separation of components into loosely coupled services optimizes scalability, maintainability and functional flexibility.


Challenges

However there are huge challenges in using SOA for creation of an EHR.

• Legacy Systems , geographically spread over wide area , fragmented , disparate data types , disparate data sources (electronic/paper), proprietary technological systems including in-house built systems

• Many governments are targeting EHR infrastructure to aid healthcare reforms which is stretching it to the limit and is beyond its intended use.

• Existing systems rich in function , poor in interoperability

• Desire to bridge legacy and provide for future extensibility of the systems is difficult due to absence of uniform standards

• Many EHR implementations are driving point of service vendors to use new industry standards which are not mature , e.g. HL7V3 and SNOMED

Pitfalls

Apart from the challenges there are a few pitfalls as well

• Not SO easy to convert closed legacy healthcare systems into open service oriented applications and databases

• Big Healthcare vendors are not “service oriented- Systems that had around for years are now cannot be suddenly, service oriented.

• New SOA Infrastructure e.g. IBM Websphere for ESB or Oracle HTB increases costs

• SOA in Healthcare not implemented and not deployed anywhere on a huge scale

EHR Patterns -Advantages and Challenges

This is an extract from a presentation which i gave recently where i have been asked to present the different EHR architecturial patterns and the advantages and challenges associated with each of the patterns

There are three types of EHR Models/Patterns which are in wide use

Ø Central Repository Model
Ø Federated Model
Ø Hybrid Model

Central Repository

Features

Ø Health record is stored at point of care systems as well as a common repository
Ø Patients record is identified by a unique identifier which may be allocated by the central repository or a national organization
Ø Local record may be a detailed record and the shared record a summary record
Ø Thin EHR

Advantages

Ø Easy and Quicker access to the data
Ø Security controls easy to implement compared to federated model
Ø Better price/performance ratio
Ø Data can be entered into the local systems or directly
Ø Allows data to be cleansed and its terminology standardized by reference to a canonical controlled vocabulary
Ø Consistent interpretation of data by different clinical settings


Challenges

Ø Determining ownership of data between organizations
Ø Infrastructure and scalability issues
Ø Decoupling and Business continuity issues
Ø Resolving conflicting data issues between central and local e.g. allergies information
Ø Governance and funding issues between different organizations

Federated Model

Features

Ø Health record is stored at their places of origin- point of care systems
Ø Patients unified record is fetched from different systems using patient indexes and record locator services
Ø The fetched record will usually be a agreed subset of data in the point-of-care systems
Ø Thick EHR

Advantages

Ø Avoids the infrastructure and ownership issues that are barriers to information sharing.
Ø Decentralized data approach safeguards privacy and security by affording a pathway that facilitates information exchange while leaving appropriate controls in place.
Ø Infrastructure can be relatively small and requires less capital and ongoing operating expense.
Ø Data can be managed locally
e.g. deletions without considering the impact on data sharing.


Challenges

Ø Appealing in theory but has many implementation and performance difficulties in practice, particularly for large systems with many records and many different federated EHR sources (or EHR nodes).

Ø Rely on a number of factors such as efficient distributed queries, short latencies, and compatible security models and are only as good as the weakest link in the chain.

Hybrid

Features

Ø Combination of the two architecture types
Ø Patients record are identified by a combination of identifiers – national and local
Ø Central record has only demographics and limited clinical data with access control and record locators for detailed data
Ø Thin and Thick EHR

Advantages

Ø Provides all of the advantages of a centralized data architecture for the most relevant clinical data required for care.
Ø Provides benefits of the federated architecture with access to detailed record
Ø Local systems still retain control of their data with access to relevant patient
data from other organizations


Challenges

Ø Deciding the scope of shared data and unshared data
Ø Different access controls required locally and centrally for similar data of a patient.

Accurate Definitions -EMR/EPR/EHR

This is a post just to clarify the different terminologies used in Healthcare informatics and I feel annoyed when people use these terms intermittently as if they all mean the same.

EMR - Electronic Medical Record

The EMR is very medically focused and usually focuses on a particular medical domain for example orthopedics. EMR can be for a particular department in a hospital or a collection of patients medical information from all departments in a given hospital site. Rarely the scope of EMR extends outside a hospital even when it does it is usually for a organization which has multiple sites but never between two hospitals which belong to different organizations. This is a widely used term in N.America and Asia-Pacific and not commonly used in European countries.

EPR - Electronic Patient Record

This is a term which has its origins in the UK and essentially has the same definition as that of EMR. However the definition of EPR by NHS as “an electronic record of periodic health care of a single individual, provided mainly by one institution” makes EPR definition more patients centric. NHS has classified EPR into 6 levels

Level 1 - Patient Administration System and Departmental Systems
Level 2 - Integrated patient administration and departmental systems
Level 3 - Clinical activity support and noting
Level 4 - Clinical knowledge, decision support and integrated care pathways
Level 5 - Advanced clinical documentation and integration
Level 6 - Full multi-media EPR on line


EHR - Electronic Health Record


Electronic Health Record (EHR) is described as the concept of electronic longitudinal collection of patient’s health and health care – from cradle to grave. It combines information from different care settings held in different systems and in some instances aggregates the data and shows them as a single record.

The Committee for European Normalization provides the following definition for EHR:

“A repository of information in a computer readable format regarding the health of a subject of care “


The Australian National EHR Taskforce, defined EHR as

“an electronic longitudinal collection of personal health information based on an individual or family and entered or accepted by healthcare professionals .It can be distributed over a number of sites or aggregated at a particular source including a hand held device. The information is organised primarily to support continuing, efficient and quality healthcare.”

Informational Governance and EHR

Most of the national EHR implementations seem to be plauged with issues concering the security of the data. Though it has been realised long back that Privacy and security are of utmost importance in the design of the EHR infrastructure enough attention has not been given by the policy makers involved in the deployment of EHR in their respective countries towards this.

A Canadian poll result indicated that the two most biggest concerns of the patients in the deployment of EHR in their country are

• Confidentiality and Privacy - 54%
• Safety of information - 31%

The key IG principles that need to be considered for building EHR are

• Restriction of access of the EHR to clinicians who currently have a duty of care for the individual concerned-The biggest issue with this principle is the decision to consider whetehr we restrict access to individual clinicans or group of cincians who are responsible for the care of the patient. It is a known fact that clinicans rarely work in silos expecially in acute settings.
  
• It should be possible to assign personally requested special levels of confidentiality to specific health information held in the EHR- Most people assume a simple Role Based Accesss is the solution for this but the key to this principle is associating multiple business activites with a role and linking thse activities to users of that role.

• EHR availability should be restricted within the organizational boundary within which it is created, except with patient consent -The issue with consent is the issues associated with explicit and implict consent and should the clinicans be able to override the dissent in case of emergenices.

• Operational staff (administrative and IT) should only have access to the minimum information required to perform their task-It is a well known fact more than outsiders it is insiders and more prominently operational staff who leak clinical data. But the issue is what level of data is minimal data ; how will the issues related to data inconsistency be resolved without operational staff looking at the data.

• All EHRs should have an automated and tamper-proof audit trail including a logof access which should be available to the patient.-Tamper proof audit trial should not be just a simple database log but much more secure than that for example we can considerr triggering alerts to responsible clinicans when patients sensitive data is viewed which shoud help mitigate this problem to a extent.

• The physical machinery storing the EHR should be protected -Proper Resilience and Disaster Recovery controls are key to this; a crucial factor is the amount of time taken to failover which is not a factor for secuirty but key factor for patient safety.