Report.tex

\documentclass[14pt]{article}
\usepackage{geometry}                % See geometry.pdf to learn the layout options. There are lots.
\geometry{a4paper}                   % ... or a4paper or a5paper or ... 

\usepackage[parfill]{parskip}    % Activate to begin paragraphs with an empty line rather than an indent
\usepackage{fullpage}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{listings}
\usepackage[hidelinks]{hyperref} %Take away the hidelinks option to enable clickable links
\usepackage{tabularx} %tabular with stretch columns
\usepackage{enumerate}
\usepackage{pdfpages}
\usepackage{pdflscape}
\usepackage[utf8]{inputenc}
\usepackage{verbatim}  % for multiline comments

%\usepackage[nonumberlist]{glossaries} % DON'T make a separate list of acronyms (but then we have tons of work to do...)
\usepackage[nonumberlist]{glossaries} % make a separate list of acronyms
\makeglossaries

% Index
\usepackage{makeidx}
\makeindex

\begin{document}

\input{./title.tex}

\begin{abstract}

\newglossaryentry{interoperability}{name={Interoperability}, description={The ability of diverse systems and organizations to work together. Please see section~\ref{sec:interopDefinition} for the meaning within health care}}

\newglossaryentry{HCP}{name={Health Care Provider (HCP)}, description={an individual or an institution that provides health care services in a systematic way}}

%\newacronym[\glsshortpluralkey=HCPs ,\glslongpluralkey= Health Care Providers]{HCP}{HCP}{\gls{Health Care Provider}}

\newglossaryentry{SALAR}{name={Swedish Association of Local Authorities and Regions (SALAR)}, description={represents the governmental, professional and employer-related interests of Sweden's 290 municipalities and 20 county councils which include the regions of Gotland, Halland, Västra Götaland and Skåne}}

%\newacronym{SALAR}{SALAR}{\gls{Swedish Association of Local Authorities and Regions}}

\newglossaryentry{CeHis}{name={Center for eHealth in Sweden (CeHis)}, description={governed by representatives of county councils and regions, \gls{SALAR}, municipalities and private care providers}}

%\newacronym{CeHis}{CeHis}{\gls{Center for eHealth in Sweden}}

\newglossaryentry{EMR}{name={Electronic Medical Record (EMR)}, description={a digitalized, systematic documentation of a single patient's medical history and care across time within one particular \gls{HCP} jurisdiction}}

%\newacronym[\glsshortpluralkey=EMRs ,\glslongpluralkey= Electronic Medical Records]{EMR}{EMR}{\gls{Electronic Medical Record}}


\newglossaryentry{EHR}{name={Electronic Health Record (EHR)}, description={an \gls{EMR} or a collection of \glspl{EMR} that can be shared across networks between different \glspl{HCP}}}

%\newacronym[\glsshortpluralkey=EHRs ,\glslongpluralkey= Electronic Health Records]{EHR}{EHR}{\gls{Electronic Health Record}}


\newglossaryentry{openEHR}{name={openEHR}, description={is an open standard specification in health informatics that describes the management and storage, retrieval and exchange of health data in EHRs}}

\newglossaryentry{PHR}{name={Personal Health Record (PHR)}, description={a health record where health data is maintained and owned by the individual it pertains to, rather than an institution or a hospital}}

%\newacronym[\glsshortpluralkey=PHRs ,\glslongpluralkey= Personal Health Records]{PHR}{PHR}{\gls{Personal Health Record}}

%Page 1: The abstract is not an abstract. It is more of a very brief introduction to the article. An abstract should contain a short summary of the different parts of the discussion etc). This is too short. Rewrite.text (method, results,


Electronic Health Records (EHR) are rapidly expanding in their use and their benefits are well known. Significant reduction in the cost of care, improved quality of care, and improved record keeping are just a few of the benefits of using an EHR. It is for these reasons that many medical institutions are rapidly adopting EHRs. 

An explosion of innovation has stemmed from this rapid adoption and has produced many different solutions from many different providers. Unfortunately, these solutions tend to store and transmit the information that they collect in formats that are not compatible with each other. In order to maximize the benefit received from these EHRs they must be able to share information between different systems and locations.

This paper reports on the various aspects of achieving EHR \gls{interoperability} by discussing how different approaches affects the end user, security considerations, and usability. Health care standards, work processes and legal and organizational issues are also accounted for.
\end{abstract}

\newpage

\tableofcontents

\newpage

%\section*{Temporary section: How to do Glossary Entries}
%
%Look at the {\LaTeX} for the Abstract section to see how add glossary entries and how to use them in the text.
%
%An \gls{interoperability} entry and EHR. Second use: EHR.
%
%%Plurals: \glspl{interoperability}. 
%Reset acronym\glsreset{EHR}. \\
%Plural: First use: EHRs. Second use: EHRs.

\section{Introduction}
\label{sec:Introduction}

\subsection{Background}
%\glspl{HCP} within Sweden use electronic computer systems to store and track patient health data. There are many different customized solutions for the various aspects of this, resulting in a complex network of systems that are unable to communicate with each other. When a patient moves or visits a hospital while on vacation the individual doctors must manually send patient data to each other. This is a complicated and error-prone process that potentially wastes the time and energy of everyone involved.

 %Added by Daniel and Henrik 22/1-12
Health Care Providers (HCP) all around the world have different needs and preferences. Depending on the location, specialization and size of the hospital they all have different views on what data is important and should be stored in a patients Electronic Health Records (EHR). On top of this they want a EHR system matching what they need to as low cost as possible. This has opened up a market for developing EHR systems all of which have different structure. As a consequence most hospitals end up with different EHR systems. This creates problems when a patient is visiting a new hospital, which might need information from the patients old hospital. The different EHR systems are unable to communicate with each other due to the structural differences, both regarding communication protocols as well as regarding what data/information should be included. 

Right now the process of retrieving the patients EHR is handled manually \cite{DataInsp} 
%\ref{Datainspektionen år 2000, Överföring av personuppgifter inom vården och omsorgen av de äldre, http://www.datainspektionen.se/Documents/rapport-aldrevard.pdf} 
and is both complicated and time-consuming as well as unreliable in the sence that errors could easily occur. The consequences of an error could potentially be severe. The patient could for example be in a very time critical condition and relies on the physician being able to quickly access all neccessary medical information. Another critical situation could occur if a physician recieves wrong information about the patient, leading to mistreatment or medication errors that could be fatal.

%Define the problem and in what context (maybe contextualize, write a story, describe a scenario? a concrete relevant scenario that occurs with persons involved)

%The setting of problems in EHR/EMR \gls{interoperability} situations. Describe what the problems related to \gls{interoperability} are within healthcare. The situation in Uppsala County, why we are doing this. What is being done on \gls{interoperability} in other areas. Describe the problems related to interoperating EHRs.

%Describe the ideal interoperating system
 %Added by Daniel and Henrik 22/1-12
\subsection{Purpose and Scope}
All over the world sharing EHRs efficiently is a problem. Enabling the sharing of EHRs on a large scale could improve the quality of the treatment patients receive. By increasing the information physicians have access to, they can more accuratly make an assessment before making medical decisions.  

Many patient records are stored electronically in different EHR systems. Regardless of what EHR system is used, the task of making them accessible to patients and physicians is theoretically feasible. By providing the nurses and physicians with the ability to access a patient's medical history from different EHR systems, the speed and accuracy of treatment could potentially be increased. However, there are many ethical, legal, and behavioral obstacles to overcome in order to achieve this interoperability.

%A world wide problem in medical records is a way to efficiently share patient medical records. Many patient records are electronically stored and the potential exists to make them accessible to patients and doctors using different systems. Enabling the sharing of EHRs on a large scale could improve the treatment patients receive by increasing the information doctors have access to when they make medical decisions. With the ability for nurses and doctors to read a patient's medical history from different EHR systems they could potentially increase the speed and accuracy of treatment. There are many ethical, legal, and behavioral obstacles associated with this initiative.

This report will try to function as a guideline for achieving interoperability between EHRs and for the purpose of understanding the issues associated with building more successful, widespread EHRs in the future. 

We will not go too much in-depth into how current EHRs work. Since almost all end-users have their own opinion about what information is most important for the EHR systems to contain, and the fact that we are computer science students and do not have the medical expertise needed to address this matter, this will not be included in the report.
%The HealthShare project conducted interviews and research into EHR development in Europe and the Unites States over the past three months for the purpose of understanding the issues associated with building more successful, widespread EHRs in the future. By inspecting current systems and talking to experts in the EHR field, the project team worked to analyze the tremendous amount of EHR knowledge and form a focused picture of a successful path to follow. Perhaps most essential to the development of EHRs is the issue of interoperability. HealthShare specifically devoted many resources towards researching the intricate relationship between interoperability and EHR systems. The lack of knowledge of this relationship has ruined many past EHR projects and is of the utmost importance for progress in this sector of medicine.



\subsection{Reading Instructions}
Depending on your background, some portions of this document may be redundant or not applicable. This represents a summary of what HealthShare (please feel free to read more about us and the project organization in section~\ref{sec:ProjectGroup}) feels would be the most relevant sections for different audiences.

These are, of course, just suggestions and you are free to read whichever sections you wish.

\begin{description}
\item[Administrators] Read Section~\ref{sec:Interoperability} on interoperability (focus on section~\ref{sec:interopSolutions}). Skip the section on technical standards unless you are interested. Section ~\ref{sec:Future} focuses on the adoption of a future system, read \ref{sec:futureLegal}~-~\ref{sec:futureUsability} about the non-technical issues. The results section is very important, focus on \ref{sec:resultsEndUser}. Section~\ref{sec:Conclusions} describes the conclusions, read this.
\item[Doctors] Read Section~\ref{sec:peopleDirect}. Read Section~\ref{sec:interopCurrent}~-~\ref{sec:interopPlans} to understand the current situation and possible solutions. Subsections~\ref{sec:TechnicalStandardsTerminology}~-~\ref{sec:TechnicalStandardsAlternative} describes what we see as the optimal solution. Section ~\ref{sec:futureLegal}~-~\ref{sec:futureUsability} describes the non-technical issues with a future system. In the results section focus on Subsections~\ref{sec:resultsEndUser}~-~\ref{sec:resultsSecurity}~and~\ref{sec:resultsUsabilityTesting}.
\item[Politicians] Read Section~\ref{sec:People} which focuses on the users and stake holders. Read Section~\ref{sec:Interoperability} as well, focus on Subsection~\ref{sec:interopSolutions} which describes the prerequisites for international interoperability. Read Section~\ref{sec:futureLegal}~-~\ref{sec:futureUsability} which describes the non-technical issues with a future system. Read Subsection~\ref{sec:resultsEndUser} in the results section, and read the conclusions in Section~\ref{sec:Conclusions}.
\item[Public] Read Section~\ref{sec:Interoperability} which describes the current situation and defines interoperability, read Subsection~\ref{sec:interopIntro}. Read Subsections~\ref{sec:technicalStandardsWhatIs}~-~\ref{sec:technicalStandardsCreation} to understand what a standard is. Read Sections~\ref{sec:futureTechnical}~-~\ref{sec:futureUsability} to understand the issues with a future system. In the results section read~\ref{sec:resultsEndUser}~-~\ref{sec:resultsSecurity}. The conclusions in Section~\ref{sec:Conclusions} are relevant so read this section.
\item[Technicians] Section~\ref{sec:Interoperability} and Section~\ref{sec:TechnicalStandards} are very relevant since they describe the interoperability standards as well as the technical standards than can be used. Subsection~\ref{sec:futureTechnical} describes the technical limitations of a future system. Section~\ref{sec:Results} lists our results and is very important. Read the conclusions in Section~\ref{sec:Conclusions}.
\end{description}

\subsection{Project Organization}
\subsubsection{Project Group}
\label{sec:ProjectGroup}
The HealthShare project was carried out during the fall of 2011 as a collaborative course between Rose-Hulman Institute of Technology, Indiana, USA and Uppsala University, Sweden.
The project group consisted of 18 students, 8 from Rose-Hulman Institute of Technology and 10 from Uppsala University. To encourage cooperation between USA and Sweden responsibility was equally distributed between the two Universities.

The project was organized in a hierarchical organization structure with two project managers, one from Sweden and one from USA. The project was then divided into four teams containing a mix of both Rose-Hulman and Uppsala students. Each team then had a team leader answering to the project managers.
%Insert a table/figure of project organization and members

\subsubsection{External Actors}
%Does Benny work for the University Hospital or the County Council
The project was carried in cooperation with and as a service to a client, Benny Eklund, IT strategist at Uppsala County Council.


\newpage

\section{Method}
\label{sec:Method}
\subsection{Interviews}

\subsubsection{Phone Interviews}

The initial objective was to find suitable people to interview, which was done by searching the web. Before conducting the actual interviews initial contact was made to schedule time with people of interest. Interview questions were prepared  beforehand and they were designed to suit the interviewee; technical questions for technical staff, etc. 

The focus of the interviews was, as mentioned, dependent on the profession of the interviewee. Overall focus, however, was always on EHRs and the possibility of interoperability between them. The different types of questions asked varied between administrative and technical, but always covered the overall focus. 

Before the start of the interview it was important to make sure to be well prepared depending on the character of the interview and the interviewee. The interviews did not follow the structure of the questions prepared beforehand; all the prepared questions were covered, but usually not in any particular order. The most important thing was to get the interviewee to talk as much as possible. After the interview, transcription and translation of the information gathered and a summary was written.

Interviews were performed with representatives of Cambio \cite{Cambio}, and epSOS \cite{epSOS}.

\subsubsection{In-Person Interviews}

Based on the relevant literature, interview templates were produced before contact was initiated. The templates were then adapted to fit with the specific interviewee's range of knowledge and sent beforehand to allow for preparation. Contact was initiated through both phone calls and email conversations, to book the time of meeting and send the interview questions.

During the actual interview, typically there would be one or more people interviewing a single person or more people from the same organization at the same time. This was more time efficient but led to that the more experienced of the interviewees doing most of the talking. As mentioned above the interview questions were prepared among the groups and were sent to the interviewees few days before the actual interviews. During the interviews we usually had one person who asks the questions while others would litsen and take notes we also recoreded most of  interviewes in order to analys the interview later on. All interviews were structured to focus on which problems exist today, how they are currently being dealt with, and how different organizations and projects correspond to it. The interviews that were recorded were transcribed and translated to English. The transcripts are available in a separate document available from the project coordinators.

\subsection{Research Methodologies }
Methods of research ranged from reading articles written by outside sources about the EHR system to technical documents created by the system itself, depending upon what was available.  While the majority of the resources were found by using the Internet, some team members found useful information in other places such as the library.  Additionally, teams had access to previous papers on similar topics which were of great use to the team.  Once resources were found, the information was read and parsed to allow other team members to answer specific questions for the benefit of others (e.g. Solutions to the problem with interoperability).  It was then important to summarize these findings so that other members of the team were able to quickly locate and use the useful information.

\newpage

\section{Users and stakeholders of Electronic Health Record}
\label{sec:People}
There are both direct and indirect stakeholders of EHR systems. Direct stakeholders are people that actively use the system: physicians, nurses, receptionists, and clerical and billing personnel. indirect stakeholders are people who do not use the system, but are benefited by its use: eg. patients.

\subsection{Direct Stakeholders}
\label{sec:peopleDirect}
According to Rebecka Janols \cite{Janols} this group of stakeholders have different primary education and care responsibilities, hence they may use the system differently depending on their individual knowledge, needs, and what kind of health issues. For instance nurses may use the system to document patient health issues or enter data from diagnostic tests, whereas physicians use the EHR system to interpret the diagnostic test and to perscribe medication. 

This group of stakeholders has to be confident that their EHR system can effectively show their patient’s illness and progress properly. This group, especially nurses, is often going in and out of the examination room where the patient is sitting. At this time they need to be aware that any information left appearing on the computer screen on an unattended terminal may be seen by other persons who are unauthorized to see. 

The other group is clerical and billing staffs. These staff members do not document patient health issues, however they spend time setting appointments, send letters to referring physicians, and inspect charges that will be submitted to insurance companies. These groups often control when and where patent health data is sent outside of the boundaries of the particular medical facility. This is an area where privacy can be violated, since there is a risk that a medical record can be sent to the wrong people by mistake. 

\subsection{Indirect Stakeholders}
\label{sec:peopleIndirect}
Patients are the most important indirect stakeholders when it comes to EHR systems. Since patients may be affected by EHR systems without directly using it they are considered as indirect stakeholders. Because patients often do not have any direct invlovement in planning and/or implementing many EHR systems have been designed without considering patient privacy. Today all systems are integrated through the whole care process, which makes it is easy to see everybody's information. This may be a problem since the medical records could be accessed or violated by an unauthorized person. According to the Swedish Patient Data act \cite{PatientDataAct} only persons who need the information in their work to provide care for a patient have the right to read the patient's medical records. However, unauthorized care givers with different qualifications may get the permission to read  about a  patient. Despite this security problem many patient in a resent study said that they are willing to make some concessions when it comes to their privacy in order to make their patient health issue more accessible with the goal of better health care due to greater transparency \cite{Merrill}.


\subsection{Work Flow Implications}
\label{sec:peopleWorkflow}
Establishing an acceptable user-centered EHR system is a challenging task for health care providers because there are many different stakeholders with different needs. As stated the EHR work flow effects for the direct stakeholders (physicians, nurses, practitioners, etc.) may vary by type of patient care facility and professional responsibility. However, the most mentioned EHRs changes involve increased efficiency and productivity as well as improved documentation consistency \cite{Allan}. These changes were mentioned because the basic system was a source of frustration and dissatisfaction for nurse, physicians and even managers. According to Allan \cite{Allan} the nursing leaders in an inner city hospital undertook a redesign process to create an effective and efficient system for documentation that also provide data for monitoring care processes, patient outcomes, and staff performance. Challenges that EHR's may present to work flow process include: increased documentation time (e.g. slow system response, system crashes, multiple screens, etc.) and reduced critical thinking through the overuse of check boxes and other automated documentation. The biggest issue is system crashes. This is because caregivers, especially at in-patient facilities such as mental health facilities where patients live there, will not know what treatments are needed or if medications are due if the system crashes. 

What is interesting is that, the national attention and rapid adoption of EHRs came at a time when the nurses were experiencing a significant decrease in workforce and an increase in workload \cite{Mitre}. In order to help compensate for this workforce disagreement, EHR implementations must correspond with workflow redesigns to ensure increased efficiencies to generate improvements in quality of care. 

\subsection{Ease of Integration}
In order to make the adoption of a new system as smooth as possible it is important that we make sure that the final system is able to easily integrate with the already existing systems for EHR handling. This can be done in a few different ways, one of the main ways of doing it is to develop a module that would extend the different EHR systems that already exist and are in use.\cite{EPJ2} For Cambio Cosmic, a health care system used in Uppsala, there is already such a module made for integration with NPÖ ("Nationell Patient Översikt", an initiative for the electronic sharing of patient records), however this module is not currently used at the Akademiska hospital in Uppsala \cite{EPJ1}.

If we decide to implement an extension module for the sharing of EHRs it is important to make sure that the look and feel are similar to the system that already exists. This is crucial in order make the system popular. 

A system for EHR sharing could also be made as an external system, however if this is done Östros\cite{EPJ2} stresses the need for it to still be somewhat integrated with the existing system. This could, for example, be done by implementing an exporting feature into the already existing system that would export the information of the active patient into the new system. This would simplify the use of the new system since it would eliminate the need of inputting the patient information multiple times.

Another very important issue to consider is the need to be able to remove certain information about a particular patient. For example, a patient who have received psychiatric care might not want that information to be left on the the patients EHR after treatment have been completed \cite{EPJ1}.


\newpage

\section{Interoperability}
\label{sec:Interoperability}

\subsection{Introduction} 
\label{sec:interopIntro}
One of the most important and prominent issues we worked on during this project was interoperability. The goal of this section of the report is to familiarize the reader with the concept of interoperability and inform them of how it affects the problem at hand. Additionaly, possible solutions to the different interoperability problems are also included in this section of the report.  Lastly, care plans will be described and it will be discussed how standardizing them could potentially help the interoperability of Electronic Health Record (EHR) systems.

\subsection{Definition within Health Care} 
\label{sec:interopDefinition}

\newglossaryentry{IEEE}{name={Institute of Electrical and Electronics Engineers (IEEE)}, description={is a non-profit professional association headquartered in New York City that is dedicated to advancing technological innovation and excellence}}

%\newacronym[\glsshortpluralkey=IEEE ,\glslongpluralkey= Institute of Electrical and Electronics Engineers]{IEEE}{IEEE}{\gls{Institute of Electrical and Electronics Engineers}}

As defined by \gls{IEEE} interoperability is the ability of multiple systems to exchange information and to use the information that has been exchanged\cite{IEEE}.  In general, if there are multiple systems that both work with the same type of information it is beneficial to all of them to be able to communicate and share information with one another. An illustrative example to think about is the different word processing applications that are available. By making it so that files created and saved with Microsoft Word can be opened and modified using Word Perfect and LibreOffice, all products benefit.  Related to this report, the ability for different systems that handle EHRs to communicate with each other and exchange data is invaluable.  Generally, there are a couple of different ways that interoperability is handled, which will be discussed in a later section.  Interoperability is a long-term investment that has a great history of paying off in the long run (both within the electronic health industry and out).

\subsection{Current Situation} %What the current situation is regarding \gls{interoperability}. Why it is a big problem.
\label{sec:interopCurrent}

This section is mainly based on the interview with Susanne Östros\cite{EPJ2}, so if no other citation is given assume an implicit reference to this interview.
The sharing of EHRs currently is not very good. If two hospitals need to share EHRs between each other it can presently be done in two different ways:

The first way is that if an EHR needs to be sent from one hospital to another, the first hospital prints out the EHR and then anonymizes this document before it is sent via fax to the other hospital. When the second hospital receives the document contact is made between the hospitals and the identifying information is communicated to the second hospital. The reason for anonymization is to make sure that even if a fax is accidentally sent to the wrong address it will not be possible to distinguish which patient the information is relevant to.

The second way that a transfer of an EHR between hospitals is conducted today is that the EHR is sent with the patient during transport. For example, if a patient needs to be moved from Uppsala to Stockholm the patient and the corresponding EHR can be sent on the same ambulance to Stockholm. The problem with this is that it can become stressful during a patient transportation since it can become a time issue, since the writing of the summary might have to be done while the ambulance is ready to go.

\newacronym[\glsshortpluralkey=ICTs ,\glslongpluralkey= Information and Communication Technologies]{ICT}{ICT}{Information and Communication Technology}

A lot of work is being done to increase \gls{interoperability}. For example, the national strategy for eHealth Sweden, which was launched in 2006 aims to increase the interoperability by bringing laws and regulations in Sweden in line with the extended use of \glspl{ICT}. It also aims to facilitate interoperable \gls{ICT} systems and make access to information across organizational boundaries. \cite{NationalStrategy} 

\subsubsection{NPÖ} %Written by Sam & Romel according to interview with Viktor Jernelöv from NPÖ.
\label{sec:npoInterv}
This section is based on an interview conducted with Viktor Jernelöv who is responsible for informatics and sematics interoperability in NPÖ.The interview was condcuted by two students in Stockholm in November 2011. 

Currently the main initiative for the electronic sharing of patient records that are in used today is something called NPÖ, "Nationell Patient Översikt" ("National Patient Summary"). According to Viktor Jernelöv \cite {ViktorJernelov} NPÖ is a project that was started during 2004 under the name Carelink. The project conducted a pilot test during the period 2005-2006, which was deployed in the Norrbotten, Stockholm, Jönköping, and Västergötland counties in Sweden.

The goal of the NPÖ system is to provide different caregivers (such as hospitals) with mirrored information from different EHR systems \cite{ViktorJernelov}. It works in such a way that when a caregiver wants to connect with the NPÖ system the caregiver can get information about a patient via a web service. Currently it is not possible to add or edit information in NPÖ, however NPÖ can be used to view patient information from different EHR systems. This could be useful, for example, in an ambulance where nurses in the ambulance can use their mobile devices to login to NPÖ and look at the patients medical record.  

NPÖ's web service has two main functions: a question, and an answer service. According to Viktor Jernelöv at NPÖ \cite{ViktorJernelov} the question service is not completely implemented and thus is not used much. The idea with the question service is to ask questions to NPÖ, e.g. show all the information about patient X and the answer services is then used to reply to this query. Today NPÖ can only be accessed by caregivers, however as reported by Viktor Jernelöv \cite{ViktorJernelov} NPÖ is working on redesigning the question service to make it more adaptable for patients and allow them to ask question directly to NPÖ.

During the pilot test experiences was gathered and used for developing a requirements specification for the future implementation of NPÖ. These experiences was used to describe which information sets that should be part of the first version of the implementation. As stated in the requirements specification the following information sets should be included in the first version of NPÖ \cite{Npotest}.
\begin{itemize}
\item Caretaker (patient identification and address, contact information to near relatives and possible interpreter needs)
\item Attention Signal (hypersensitivity to drugs, serious illness, serious treatment, care restrictions and contamination)
\item Diagnosis (determining the patient's illness, injury, disturbance or change in body function)
\item Personal care and service (primary care, specialist care, assisted living, home care and special housing)
\item Pharmaceuticals (of the caregiver ordained, by the care provider prescribed and picked up from the pharmacy)
\item Personal care contact (care and recipient of care, who is responsible, care contact type, contact reason, time for health-care contact's start and end and personal care and contact status)
\item Care Document (epikris, admission notes, day note, outpatient notes, outpatient summary, specialities note and other documents)
\item Operation Permits (personal activities of daily living and disability)
\item Care planning (plan that describes planned and decided on health care for affected individuals)
\item Findings (clinical chemistry, microbiology, ECG with text and pictures via link, image diagnostics with text and pictures via link and consulting)
\end{itemize}
Each of these information sets is a delimitation of the full information set. The first information set Caretaker is always included because it contains information about patients ID and administrative information for example patients address and their relatives. Whenever a caretaker wants to connect to NPÖ they have to first choose which information area they want to connect to. Although the integration between EHR systems and NPÖ is not strictly bounded, NPÖ has some requirements which all caretakers have to follow. For instance, NPÖ tells the caretakers what the patient information should look like and which attributes it should contain, then it is up to the caretakers to fulfill the requirements and follow the structure. The caretakers are also responsible for updating the information in the NPÖ. 

One of the main technical problems with the NPÖ is handling the removal of information from the system. Whenever a caregiver deletes information in the local EHR system they have to delete the same information in NPÖ manually. Since they delete information from the core database in a local EHR system it is difficult to recover deleted information because the system does not recall of ever having it. This is a problem if it is deleted by accident. Many caregivers solve this problem by making someone an administrator who deals with only deleting information on both local EHR systems and NPÖ  \cite{ViktorJernelov}.

Many patients today expect a high level of electronic interoperability when it comes to their patient records\cite{EPJ2}, something that does not exist today. One reason for this shortfall is a lack of familiarity with the current laws in place as well as believing that patient data is shared between different counties \cite{EPJ2}. This creates risks of misunderstanding if the patient assumes their patient records are accessible at every hospital in Sweden even though just a summary of their data is available through the NPÖ-system.
\label{sec:npoInterv}
\subsubsection{NPÖ adapter}
\label{sec:npoIntervi}
\newglossaryentry{EN13606}{name={EN 13606}, description={A European EHR Communication Standard by \gls{CEN} and \gls{ISO}. Defines an information architecture for communicating part or all of a single patient's EHR}}

The Electronic Health Record (EHR) system Cosmic provide an all-inclusive soultion for large, complex organisations providing care across a wide geographical area. Cosmic has about 50.000 users in Sweden, Denmark and United Kingdom. Cosmic can be integreated with other existing systems. The system has different modules for example, Medical record, Drugs, Referrals and resource planning. In addtion to that it has a Capture/Compare/PWM(CCP) language module on top of it which allows other systems to extract information from it. The CCP module is software programmable to operate in one of the follwoing three modes: 1.Capture input 2.A compare output 3.A Pulse Width Modulation(PWM) output for the CCP module to function. 

On top of the CCP module, Cosmic has built something called NPÖ adapter. This NPÖ adapter takes the data that the CCP module produces and translates it to \gls{EN13606} format. The \gls{EN13606} is a European Standard Electronic Health Record Communication which enables cross sectoral exchange of medical data and this standard is needed to communicate with NPÖ. The NPÖ Adapter is illustrated in figure 1. As can be seen in the figure communication between EHR systems and the NPÖ adapter can be in any format, but the NPÖ adapter communicates with NPÖ in \gls{EN13606} format. The reason for doing this is to avoid having the \gls{EN13606} as a communication format between the EHR systems and the NPÖ adapter. This is because the \gls{EN13606} is a complex and abstract format. It is therefore an advantage to use a simpler format to between the EHR systems and the NPÖ adapter. Another advantage is that there only needs to be one transformation: the 13606 transformation between the Local Connection Point and NPÖ  \cite{ViktorJernelov}. (see Figure 1) 

\begin{figure}[h!]
  \caption{NPÖ Adapter: Communication Architecture between COSMIC and NPÖ}
  \centering
    \includegraphics[width=0.55\textwidth]{Images/npoNewAdapt}
\end{figure}\
\label{sec:npoIntervi}

\subsection{Solutions}
\label{sec:interopSolutions}
There are two takes on the solution to interoperability that are generally accepted.  Since interoperability is essentially making sure that two or more systems can exchange information, the two most popular solutions are to either make sure that all systems are capable of using the same data formats (Syntactic) or there exists some way for the systems to automatically interpret other data formats that they do not support (Semantic).

Of course, each of these solutions comes with both advantages and disadvantages.  While semantic interoperability might be quicker and less work at first, it is not practical if the number of systems is going to be expanded. In this case, each addition of a new data format requires the automatic interpretetion process to be updated.  On the other hand, implementing semantic interoperability only requires that you know the output of the system for the changes to be made, while syntactic interoperability requires complete knowledge of the system as a whole for the changes to be made.  In return, syntactic interoperability is more work up front but does not require any of the existing systems to be modified when new systems are added.

To achieve European wide solutions for cross-border transfer of patient information certain requirements need to be fulfilled. There has to be an agreement on the definitions of data sets for both patient summaries and e-prescription, a legal framework for data transfer, a technical framework to connect the systems at each level, and a working semantic \gls{interoperability}. \cite{epSOS1}

\subsection{Motivation}
\label{sec:techMotiv}
During our research Farzin Yazdi, laboratory technician at Karolinska University Hospital, Stockholm, and previously at Rigshospitalet, Copenhagen, was interviewed. According to Yazdi\cite{FarzinYazdi}, the importance of interoperability between EHRs is high because it is easier to exchange information between EHRs when those are connected together \cite{FarzinYazdi}. If EHRs are not connected to each other, there is risk for double labour i.e. copying patient data from primary EHR to the secondary EHR twice\cite{FarzinYazdi}. By doing this task manually is time consuming and there is risk for mistakes, than with interoperating EHRs\cite{FarzinYazdi}.

At Karolinska University Hospital in Sweden, the employees use three different EHRs which are not connected to each other, or systems used for analysis in the laboratory \cite{FarzinYazdi}. This makes the work much harder and confusing because they have to decide which EHR to choose. This working routine will result in many incorrect data registration. Since analysis systems are not connected to EHRs the technicians are not able to validate samples from conducted analysis. The validation must be done manually, and the results needs to be input to the  EHR system by hand\cite{FarzinYazdi}. It is natural that a connection between the EHRs will decrease incorrect data registration. The employees at Karolinska hospital in Sweden are very much aware about this problem \cite{FarzinYazdi}.

At Rigshospitalet in Copenhagen (Denmark), the employees use two different EHRs. One of these EHRs has been installed couple of years before the other one. The older EHR has less functionality, lower user interface and it is not possible to upgrade it to the newer system \cite{FarzinYazdi}. The new system did not integrate with the old system at all. All the data from the old system were preserved and could not be reached in the new system \cite{FarzinYazdi}. The analysis systems are connected to EHR and the results are automatically saved in the EHR system \cite{FarzinYazdi}. The fact that new system is built upon a completely new platform, made adoption difficult for the end user\cite{FarzinYazdi}.

One of the big problems that technicians face is that confusion occur when two employees with different backgrounds exchange information. E.g. there is a mismatch between employees understanding of the conducted analysis's system code and full text name, which might cause misunderstanding and confusion among users\cite{FarzinYazdi}. According to Farzin Yazdi\cite{FarzinYazdi} it is important that system codes, units and names of each laboratory analysis are standardized.

Using new EHR system makes employees feel uncomfortable since they are used to work with the previous EHR system. One of the most complains about using new EHR systems is that employees should adapt themselves to the new platform that it is unfamiliar for them \cite{FarzinYazdi}. The other reason is that they don’t really know if all the functionality from the legacy system are available in the new system. Hospital staff also need to learn new features that wasn't available in the previous system \cite{FarzinYazdi}.
\label{sec:techMotiv}

\subsection{Care plans}
\label{sec:interopPlans}
%Lastly, care plans will be described and it will be discussed how standardizing them could potentially help the interoperability of EHR systems
%TODO: Add bibliography entry and use it in the other parts of the report
In health care, nursing care plans are used to prioritize diagnoses, set up goals, and decide on nursing interventions. Preferably, a classification system is used to improve consistency of terminology. Care plans are also being used within social services to clarify purpose, duration, needs, and planned actions within inpatient care of young people. In Sweden this is required by law \cite{SocialServices}.

From our interview conducted with Lars Midbøe, Kristi Dahlman, Marie Fogelberg Dahm and Helen Broberg from \gls{CeHis} in Stockholm in November 2011 we found out that there is an initiative from CeHis to standardize these care plans at a national level in Sweden. Preceded by research on the feasibility of a national information structure, the purpose is to define use cases, support equal care and patient safety, and clarify and verify the applications of standardized care plans compared to the currently existing local ones \cite{CeHis}.

If NPÖ would adapt to the idea of standardized care plans then it might not only help with the semantic interoperability but also in increasing NPÖs impact on the effectiveness of health care provider's (HCP) work routines, thereby increasing the overall benefit of the system at a regional level \cite{Cambio}.

Designing EHRs to encourage the users to follow standardized care plans increases interoperability. When using a standardized care plan, the user needs to document only the deviations from the plan and the small amount of data relevant to them such as observations. The documentation process should be as automated as possible, to enable the health care professional to devote more time to the patient instead of administrative work. This also reduces the tendency of medical staff documenting for their own sake instead of for the one that will treat the patient next \cite{Cambio}.

\newpage

\section{Technical Standards}
\label{sec:TechnicalStandards}

\subsection{What is a Technical Standard for Computer Software?}
\label{sec:technicalStandardsWhatIs}
A technical standard is a set of recognized and established requirements about software systems that establishes the ``way things should be done". Standards are responsible for the uniformity of web browsers (although not all browsers strictly conform to the standard), the ability for laptops or tablets to connect wirelessly to any access point, and the ability to connect laptops to almost any projector.

Software standards specify aspects of a program such as: the format for data storage, format for data transfer, and format for data layout. This allow different developers, working for different companies, to develop different software programs while still allowing for \gls{interoperability} between them. Software standards are the foundation for software \gls{interoperability}.

\subsection{The Creation of a Standard}
\label{sec:technicalStandardsCreation}
For different parties (software development companies) to agree on software standards they typically create an organization consisting of representatives from the the various software companies. This gives them a forum to contribute ideas and opinions about making a single, unified standard addressing the data \gls{interoperability} problem that needs to be addressed.

Below are some examples of Software Standards Organizations:

\newglossaryentry{SOAP}{name = {Simple Object Access Protocol (SOAP)}, description = {is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks}}

%\newacronym[\glsshortpluralkey = SOAPs, \glslongpluralkey = Simple Object Access Protocol]{SOAP}{SOAP}{\gls{Simple Object Access Protocol}}

\newglossaryentry{HTTP}{name={Hypertext Transfer Protocol (HTTP)}, description={a networking protocol for distributed, collaborative, hypermedia information systems}}

%\newacronym[\glsshortpluralkey=HTTPs ,\glslongpluralkey= Hypertext Transfer Protocol]{HTTP}{HTTP}{\gls{Hypertext Transfer Protocol}}

\newglossaryentry{XML}{name={Extensible Markup Language (XML)}, description={a set of rules for encoding documents in machine-readable form}}

%\newacronym[\glsshortpluralkey=XLMs ,\glslongpluralkey=Extensible Markup Languages]{XML}{XML}{\gls{Extensible Markup Language}}

\newacronym[\glsshortpluralkey=HTML ,\glslongpluralkey= Hyper-Text Markup Language]{HTML}{HTML}{Hyper-Text Markup Language}

\newacronym[\glsshortpluralkey=IETFs ,\glslongpluralkey= Internet Engineering Task Forces]{IETF}{IETF}{Internet Engineering Task Force}

\newglossaryentry{W3C}{name={World Wide Web Consortium (W3C)}, description={An international group responsible for web standards such as \gls{HTML}, \gls{HTTP}, and \gls{XML} networking protocol for distributed, collaborative, hypermedia information systems}}

%\newacronym[\glsshortpluralkey = W3C, \glslongpluralkey = World Wide Web Consortium]{W3C}{W3C}{\gls{World Wide Web Consortium}}

\begin{itemize}
\item \gls{W3C} - Responsible for web standards such as \gls{HTML}, HTTP, and XML 
\item Institute of Electrical and Electronics Engineers (IEEE) Standards Association - Responsible for a wide range of standards for engineering such as the 802.11 standard
\item \gls{IETF} - Responsible for providing standards for new Internet related technology 
\end{itemize}

\newacronym[\glsshortpluralkey=FDICs ,\glslongpluralkey= Federal Deposit Insurance Corporations]{FDIC}{FDIC}{Federal Deposit Insurance Corporation}

\subsection{Adherence to Standards}
Adherence to a particular software standard can be either mandatory or voluntary. For example: in the United States banking software must conform to security standards and regulations set forth by the \gls{FDIC}. Any system that does not conform to these standards faces legal action by the United States federal government and as such is not allowed to be used by U.S. banks. On the other end of the spectrum are the standards set forth by the W3C as to how a web browser should interpret and render various web pages. These are completely voluntary standards and while most popular, modern browsers conform to a majority of these standards, there are no browsers that achieve complete compliance. They face no legal action for not complying with the W3C standards because they are voluntary, not legally mandated.

\subsection{Software Standards and EHR Software}
With the growing ubiquity of the Internet, computers, and modern technology as well as the geographic diversity of medical talent and information, it is doubtless that someday a standard specifying the transmission, storage, and format of electronic health care records will be developed; the benefit of such a standard is too great to be ignored. Because patent data is widely varied and medical breakthroughs are discovered daily, any standards regulating Electronic Health Records (EHRs) will need constant revision and modification to stay relevant. Such a standard will require a large international organization to oversee and develop.

\newacronym {IHTSDO}{IHTSDO}{International Health Terminology Standards Development Organization}
\newacronym {SNOMED}{SNOMED CT}{Systematized Nomenclature of Medicine - Clinical Terms}

\newglossaryentry{HL7}{name={Health Level 7 (HL7)}, description={A standard organization focusing on the development of international health care informatics interoperability standards}}
%\newacronym {HL7}{HL7}{\gls{Health Level 7}}

\newglossaryentry{ISO}{name={The International Organization for Standardization (ISO)}, description={A standard setting organization concerned not only with health informatic standards}}
%\newacronym {ISO}{ISO}{\gls{The International Organization for Standardization}}

\newglossaryentry{CEN}{name={The European Committee for Standardization (CEN)}, description={aims to provide infrastructures for the development, maintenance and distribution of coherent sets of standards and specifications in Europe}}
%\newacronym {CEN}{CEN}{\gls{The European Committee for Standardization}}

\subsection{Terminology}
\label{sec:TechnicalStandardsTerminology}
In order for interoperability to be useful, everyone reading the Electronic Health Record (EHR) needs to have a common understanding of the information in it. One way to achieve this is by using a common a standardized clinical terminology system.

\subsubsection{SNOMED CT}

\gls{IHTSDO} is a non-profit organization dealing with standards and at the moment 17 countries are members of the organization; among them are Sweden, the United Kingdom, and the United States of America. \gls{IHTSDO} acquired \gls{SNOMED} in 2007 and made it more accessible for a wider audience. \gls{SNOMED} is currently available in US English, UK English, Spanish, Danish, and Swedish and is being translated into French, Lithuanian, and several other languages as well \cite{ihtsdolang}.

\gls{SNOMED} is built up on 311 000 active concepts and is continuously growing. The basic concept behind \gls{SNOMED} is that each medical term has its own unique ID and all these terms are connected by semantic relationships. On \gls{IHTSDO}s website they describe the relationships like this: One type of link is the “IS\_A” relationship. This is used to define a concepts position within a hierarchy, e.g. Diabetes Mellitus IS\_A disorder of glucose regulation."\cite{ihtsdocomp}. If health care information and patient data is structured differently at different health care providers (HCP), searching for specific data in a patient journal and exporting data to other systems gets harder, \gls{SNOMED} aims to address this problem.

By having unique identifiers for all terms, translation between different languages is possible. Every language has the same identifier on their respective term, so when they store a record it is stored as just numbers. This only happens in the back-end so the user will see the medical record written in their own language.

\gls{SNOMED} is centrally updated twice a year where they add new terms and set some terms inactive. In order to support previous versions they never delete terms, but instead mark them as inactive and suggest using the newest term.\cite{annavik}

\subsubsection{The HL7, ISO and CEN standards}
\gls{HL7}, \gls{ISO} and \gls{CEN} are the main health informatics standards development organizations. They have developed HL7 version 3 and \gls{EN13606} which are meant to supplement the \gls{SNOMED} standard in providing prerequisites for EHR \gls{interoperability}.

HL7 version 3 and \gls{EN13606} form one step in accomplishing national information structures. From the interview with Johan Thorwid \cite{Cambio} we learned that the HL7 v2.3 is hard to implement and incomplete due to the additional support information needed for the application to be truly useful. HL7 3.0 was designed with the aim of dealing with this issue – it was supposed to support all health care work flows. Among other things, it uses concepts similar to the archetypes and templates of \gls{openEHR}, an open standard specification in health care informatics, and it specifies different communication formats. However, it was never adopted in Sweden. In Sweden \gls{EN13606} is used instead. HL7 version 3 is however used in England \cite{Cambio} and within epSOS \cite{epSOS}.

\subsection{Ideal EHR Standard}
All medical institutions have different needs and demands which often very significantly. This makes it exceedingly difficult to create a "one-size fits all" Electronic Health Record (EHR) standard. According to us an ideal EHR should be easy to use and learn, which can be achieved by taking advantage of existing user behaviour. Further an ideal EHR should be reliable and secure, maximize healthcare productviity by reducing the time spent handling administrative activities, and provide interoperability that stimulates existing and future workflows (e.g. interoperability between seperate health care units). In our opinion an ideal EHR standard will follow the trend of historically successful interfaces and will closely replicate legacy paper health records. It would also store the records in a standardized format as this maximizes interoperability and data mobility but also allows for the interfaces to the system to be customized for a specific institution. Customizing each EHR for a specific institution adds overhead development and maintenance costs but maximizes the work flow productivity at each facility while maintaining interoperability. 

\subsection{An Alternative to a Future EHR Standard}
\label{sec:TechnicalStandardsAlternative}
The only other option that achieves interoperability for sharing health care records would be a single unified software system that practitioners all over the world would use to view and modify patient records. Such a solution is unrealistic for two reasons: there are already too many Electronic Health Record (EHR) software companies to reasonably plan for one new company to globally take over the entire EHR industry, and with anti-trust laws as well as fair competition clauses in many countries (such as the United States and Sweden) a single organization would not be legally allowed to be the sole producer of EHR software systems.

\newpage

\section{Adoption of Future Systems}
\label{sec:Future}

\subsection{Technical Limitations}
\label{sec:futureTechnical}
The technical limitations for an Electronic Health Record (EHR) system are multi-faceted. Two separate approaches to a solution are outlined in the United States’ Department of Health and Human Services paper Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology. \cite{AMA} 

One solution is to use \gls{SOAP} which is a specification for exchanging structured information. This setup relies on eXtensible Markup Language (XML), a remote procedure call, and HyperText Transfer Protocol (HTTP). Significant existing software infrastructure and development already exists and SOAP is a way to re-use work that has already been done. This solution is dependent on multiple different systems and if one of the needed layers malfunctions the system as a whole will stop working. 

Additionally, because XML formatted data is used, SOAP systems are usually slower and more data-heavy than other options. This might cause scalability problems for a large system. These limitations to the design may cause future problems implementing a \glspl{SOAP} style system on a large scale.

The alternative is to use other transport standards than SOAP, such as Minimum Lower Layer Protocol which is used by HL7. SOAP is a trade-off however: the ability to work practically everywhere and stand on top of hundreds of existing standards comes with significant overhead and additional complexity. Very few other systems, however, have the ability to deal with data as complicated as what is found in EHRs.

\subsection{Legal Issues}
\label{sec:futureLegal}
The Swedish Safety Data Act provides new opportunities, but not obligations. \cite{RiR19} Electronic health records (EHR) exist to promote patient safety, high quality health care and minimized cost. It is also supposed to be a source of information for the patient (ch 3, § 2). A patient record must be kept for each patient and may not be common to several patients. The one writing in the record is responsible for that part. All record entries must be written in Swedish. \cite{PatientDataAct}

The patient is not required to give their consent for the health care providers (HCP) to act according to what the Patient Data Law dictates, except for an EHR to be shared from one caregiver to another, when gaining electronic access to records of another care unit or during unified journaling. Patients may refuse to be part of organized records (kvalitetsregister). To remove parts of a record there needs to be convincing reasons, the part being removed can't be necessary for future health care, and there should be no public interest in keeping the information. Record data may be blocked from unified journaling, i.e. that several HCPs can access a patients record, but the information saying that data has been blocked and by who should still be available. 

A caregiver may only have access to documented information if they directly participate in the care of the patient or need this information for their work in health care. The law also regulates periodic checking of the logs. The patient has rights to obtain certain parts of their medical record and information on who has accessed it in the past.\cite{PatientDataAct}

The Personal Data Privacy Act (1998:204) applies to the parts of the records that are managed automatically and stored in a structured fashion. The National Board of Health and Welfare has rights and obligations regarding apprehension of medical records in the event of legal violations.\cite{PatientDataAct}

According to the Swedish Patient Safety Act (2010:659), a caregiver must immediately inform a patient who has suffered a medical injury about the injury, planned preventive measures, complaint and compensation
options and the patient councils activity. Information on the information provided shall be recorded in the patient record.\cite{PatientSafetyAct}

If, with regard to the purpose of ongoing health care, it is of considerable importance that the data is not provided to the patient, then the caregiver is not allowed to do so. The same applies if there is risk of violence or permanent damage to the patient should the information be disclosed. Unless required to by law, a caregiver is not allowed to disclose details of health or personal conditions about a patient to outsiders.\cite{PatientSafetyAct}

\subsection{Organizational Issues}
\label{sec:futureOrganizational}
%[Emil and Erik: Current organizational issues that limit the adoption of interoperating systems.]
This section is very much based on an interview conducted with Reinhard Hammerschmidt, a research consultant, and Jess Heywood a junior research consultant, at the research and consulting firm Empirica. The interview was conducted by two students in Uppsala in October 2011.
\\\\
In order to successfully implement a new system for Electronic Health Records (EHR) sharing all the layers of the organizational effort must be involved including practitioners, nurses, administrators, etc. Since this will change the way people work and what responsibilities they have everyone involved must commit to the system change effort in order for the switch to go well.

In order to get all layers of the organization interested in the integration process it is important to involve them in the development of the system. Instead of having just the managers talking to the developers, all of the layers should be involved in the development stage of the system so that they feel like they have a say about the system that they will eventually use.

When developing EHR systems it is important to have clear objectives, ability to continuously revise, and most importantly strong project leaders with the backing of top level management and politicians~\cite{Empirica}. This ties in to the previous topic of having all the layers of the organization involved in the development of the system. When implementing new features or changing existing ones developers need to ensure that they listen and understand what users want. Users are seldom completely certain of exactly what they want and that makes it easy to make changes based on misunderstandings.

\subsection{Usability Issues}
\label{sec:futureUsability}
%[Romel: One problem is to identify the people responsible for the systems usability.]
The aim of establishing a successful Electronic Health Record (EHR) system is to improve efficiency, effectiveness, and support the clinicians in their practice to perform high quality care. Clinical professions have different clinical practices and use the system differently. This can cause problems because some of them feel the system does not support their clinical practice. Usability has thus been cited as a major factor in both acceptance and effectiveness of EHR in the clinical settings. Below are some key usability issues in EHR systems as stated by Janols\cite{Janols}  
\begin{itemize}
\item Not intuitive - lack of patient overview especially for the physicians
\item Many clicks - cumbersome navigation
\item Time consuming - response time e.g. downloading list of tab results can take minutes if a patient have many tests
\item Does not support work routines - flaws in design leading to threatening situations:  e.g. unclarity about dosage in the  prescription module.
\end{itemize}

There are many potential reasons for this lack of attention on EHR usability. One problem is to identify the people responsible for the systems usability. Janols \cite{Janols} examined how a large Swedish county with several healthcare units works with usability problems in the EHR deployment process. Janols \cite{Janols} showed that there is confusion about the responsibility for usability issues with the organization. The confusion is because some of the stakeholders consider the EHR system to be an IT system, not an integral part of the health care process. Others consider it to be a core business system and therefore the core business responsibility. This confusion and uncertainty about responsibility leads to an unsustainable work situation for the care staff that needs an effective EHR system to perform a high quality work.

%Here are related items from the Empirica interview
%\begin{itemize}
%\item When it comes to \gls{interoperability}, technical issues and standard specifications are subordinated to legal and organizational %issues. The organizational issues include common understanding from people involved in the process and getting the commitment from %doctors and nurses. 
%\item Clear objectives and strong project leaders with the backing of the top level management and politics are very important factors of %success for EHR projects. Continuous development and the ability to revise things are also crucial.
%\item It is important to reach all the layers of the health care organization to achieve change, to engage the different groups of doctors, %nurses, secretaries, technicians and not only have the software developers talk to the management section of the organization.
%\item Electronic systems are changing the way doctors work and what responsibilities they have.
%\end{itemize}

\newpage

\section{Discussion of Implementation Aspects}%Used to be Results/Discussion
\label{sec:Results}
%\subsection{Types of solutions and implications for the end user}%Remove
\label{sec:resultsEndUser}

\subsection{Integrate Functionality vs. Standalone Application} %Used to be Integrated vs. Standalone Application   // Emil 26 march
When designing an interoperating EHR system the choice is to either integrate interoperating functionality into an existing EHR application or to create a standalone application capable of retrieving e.g. distributed patient information and make it accessible to the individual systems.

\begin{center}
	\begin{tabular} { | l | p{4.5cm} | p{4.5cm} |}
	\hline
	& Existing EHR & Standalone Application \\ \hline
	\emph{Complexity of work environment} & Using a single application lowers the burden on the memory of the end users. Adding additional features makes the already existing system more complex. & Requires the end users to multitask which burdens their memory. \\ \hline
	\emph{Learning vs. knowing} & Benefits from existing system knowledge. & The end user has to learn a new system in addition to systems already in use. \\ \hline
	\emph{User behaviour} & Changes to existing systems interferes with the users current usage preferences. & Maintains the legacy system intact, but requires changes in behaviour of the end users to adapt to a work environment with additional applications. \\ 
	\hline
	\end{tabular}
\end{center}

A standalone system could be implemented either as a desktop application or in a web application. From a usability perspective a standalone application could cause a few usability issues. The standalone solution does not take advantage of the users knowledge of the legacy system as they have to learn a new user interface specific for the interoperating system. A workaround for this could be to allow individual hospitals to customize the end user interface to accommodate differences in user needs. 
Another issue is that a standalone application forces the end user to multi-task between the legacy EHR system and the new interoperating application. This increases the complexity of the work environment as it does not take advantage of cognitive abilities available to humans, and adds an additional burden on the memory. 

A solution integrating into the existing EHR systems on the other hand takes advantages of what the user already knows, decreasing the need for them to change their behavior patterns. The user can do all the work in the system they are currently using.

There might still be need for changes in the existing systems as they way information is handled need to conform to common semantic standards. This would render changes both in the end user interface and the behavior of how they interact with the system. Integrating interoperability into existing systems does not increase the end users need for multitasking or burdens the short-time memory. It also supports diversification in the end user interfaces encouraging competitiveness and customization.

%Usability implications
This integrated solution is supposed to have as small implication as possible for the users. There might be some small changes as the systems that they are currently using may have to change a bit to be able to meet the standards that are going to be used. As the semantics, the words and phrasings used and their corresponding meaning, have to match, some users may need to change how they write. However with a integrated solution the user can do all the work in the system they are currently using. Most of the old systems will still be intact and the users can use the old knowledge and experience when navigating.

\subsection{Use of Standards} % Used to be "Standards" // Emil 26 march
\label{sec:resultsStandards}
To make a system that interoperate between different Electronic Health Record (EHR) systems a standard have to be set and forced onto the systems. 

One way to achieve interoperability between EHR systems is for different vendors to agree on common standards. Such standards might be forced upon already existing systems and creates means for the EHR systems to share data in a way that all the systems can interpret and process. There are currently several overlapping standards in development concerning EHRs.

Before sending the data to other EHR systems, an interface or adapter is needed to transform the data into a set standard. The Swedish National Patient Overview (Nationell patientöversikt, NPÖ) uses an adapter to translate information from the originating systems into a set of common standards. 

One of the obstacles for implementing a system upon a common standard is getting several different actors from varying backgrounds to unite and agree on a solution. To be able to make this work the different systems need to use the same semantics for medical terms and therefore some users may have to change what words they use when they enter data into their EHR system. The interface of the systems might also change, since the way information is entered and presented will have to conform to the standards. In the end this situation would lead to implications on the end users behaviour when interacting with the system. Some EHR systems will be affected by required changes to a greater extent than others, thereby leading to a higher degree of imposed changes to the end users behaviour than for the systems not so heavily affected.

\subsection{Data Location Policy} % Used to be Data Locality // Emil 26 march
\label{sec:resultsLocality}
\newacronym[\glsshortpluralkey=HCUs ,\glslongpluralkey= Health Care Units]{HCU}{HCU}{Health Care Unit}

Achieving interoperability between current Electronic Health Record (EHR) systems implies that patient information is made available throughout all connected Health Care Providers (HCP), or more specifically Health Care Units (HCU, the hospitals, institutions, etc.). This raises a few concerns regarding overall system performance and the ownership, responsibility and control of data. The question is whether information should be kept in a centralized or decentralized manner.

Storing the data centrally could decrease the search and retrieval time for accessing a health record as the information is kept closer to each individual \gls{HCU} \cite{Cambio}. Keeping the data centralized will require large amounts of data storage and intensive traffic between the connected health care units which may seem problematic at first, but is not a very serious problem since (according to an interview with Johan Thorvid \cite{Cambio}) not all data will have to be kept centrally. This is because up to 60\% of the storage at local hospitals is used for version tracking.

Allowing patient information to be stored centrally will also require that \gls{HCU} allows giving up some of their control over the data. One possibility is that the system might be required to provide functionality for \glspl{HCU} to remove information available in the central domain upon patient requests. Another issue would be to ensure that data is consistent between individual health-care and the central system, as patient information is updated. An implemented system also has to ensure that updates are comitted to the central system within acceptable time for the \glspl{HCU} to be capable carry out their responsibilities to patients.

On the other hand a decentralized system where the information is kept at each individual health-care unit allows higher control of the patients information. When requested by a secondary \gls{HCU} the information would only reside outside of the system for a temporary time. There might still be a need for a central index of what information that is available at each \gls{HCU}, to avoid large amounts of data traffic flooding hospitals with requests for patient information. A benefit from having a decentralized system is that it to some extent guarantees that the retrieved information is up to date as it is retrieved upon access, assuming that the index is kept up to date.

\subsection{Security Considerations}
\label{sec:resultsSecurity}
Any system maintaining sensitive personal information needs to be secure and protect the data from unauthorized access. This is certainly true for Electronic Health Record (EHR) systems, but there are additional issues to address. Different levels of security can be used, but a minimum standard security level for authentication in the system must be set among all interoperating systems. This to ensure that the required security level of one Health Care Provider (HCP) is maintained as the data travels to another HCP. In an integrated system all users must authenticate themselves to be able to access information. It is therefore required that every EHR system fulfills the required standard for security. In a standalone system the system itself will have to meet the same requirements as the existing EHR systems. The communication between different parts of the interoperating system could be handled either over an intranet or on the Internet. An intranet allows a higher degree of control in terms of who can connect to the system, as you are in control of who that has access to the intranet. As an intranet grows, with the possibility of communication across border, it becomes harder to maintain this control, increasing the need for encryption and other protective mechanisms. The alternative is to handle communication over the Internet with a high degree of security in terms of state of the art encryption and authentication. On the Internet the threat of malicious traffic and software increases. New threats constantly arise across the Internet in varying forms, stressing the need to update and maintain the security in the interoperating system.
The implementation of \gls{PHR} features in the system, accesible on the Internet, would require exposing a subset of the information to the Internet.

%Security Testing
During the interviews the issue regarding security came up as an important factor to consider in an interoperable system. It is always important to handle the security with great care when it comes to patient information, but the security issues might be a lot greater when dealing with a system of bigger size such as when multiple EHRs is interoperating. One example of a feature that might need improvement is the access control of patient information due to the fact that an interoperable system will increase the amount of reachable information. Ordinary methods for checking access control such as going through logs might be inefficient and costly and new methods might be needed.


\subsection{Development Strategy}
The interviews with administrative personal and technicians were focused on what they thought would be required to create interoperability between Electronic Health Records (EHR) rather than what they would want in such a system. 

One of the most important things learned from these interviews was that development of an interoperable system would be very complex. It is hard to set a definite end in such a big development process and the process should be considered on-going where the focus lie on completing sub-goals rather than only shooting for the final goal. These characteristics imply that an agile development method would be suitable for such a task.

\subsubsection{Agile Methods} %\subsubsection{AGILE}
Agile development is an iterative and incremental development process where the work is done in small steps and every step is evaluated. The small steps could be subparts of the final system. Starting off with a smaller part of the system, ensuring that this part works and then move on by adding more features or go on to the next part of system might be more successful than trying to complete the whole system at once. However, agile development can be very time consuming and is not an option if there is a short amount of time to complete the project. It is therefore important to consider and evaluate the amount of time and resources available for the project, and weigh this against the overhead caused by the iterative methodology in agile development.

\subsubsection{Using Communication Requirement Domains} %\subsubsection{Requirement Domains} % New title:  7.5.2 Using Communication Requirement Domains    , move to correct place (after Agile methods, under Development Strategy)
Deploying an interoperating system requires the involved Health Care Providers (HCP) to agree on communicating in specific ways. This will render a set of communication requirements to be forced on each hospital. 

A similar interoperability problem was solved when deploying a system for border management within the European Union. Border management systems involves both private and government actors from different nations. The specification of the system was then divided into different domains with different levels of mandatory, optional and recommended requirements based on how they interact with other parts of the system. \cite{BorderMgmt}
%% Reference: Border Management Modernization, The World Bank, 2011, ISBN 978-0-8213-8596-8, Gerard McLinden et. al.

Communication requirements can be divided into different domains depending on their importance. For example, how to communicate with a central system would be a mandatory requirement. Other such requirements could be recommended or optional, giving the individual HCPs guidance and a higher degree of freedom for how to implement communication between Electronic Health Record (EHR) subsystems. 

\subsubsection{Usability Testing}
\label{sec:resultsUsabilityTesting}
Another important aspect that came up during the interviews was the involvement of the end-user in the development process. Physicians, nursers etc. are the end-users of the interoperable Electronic Health Record (EHR) systems considered in this report. If the development of the interoperable system can not be done only in the back-end, meaning that the end-user's systems will be affected, their opinions will be of importance. In this case the change in the systems might be made in a way that does not affect the end-users negatively if their opinions are taken into consideration in the development. Even if there is no need for noticeable changes their opinions can still be of importance when it comes to what kind of patient information is most important to share in the interoperable system if it is unmanageable to share all information. 

The involvement of end-users can be included in the agile development by letting them take part in the evaluation of the sub-parts where their opinions matter. 

\subsubsection{Internet Access or Not}%\subsubsection{Personal Health Records}% Should be moved to after usability testing, under Development Stratedy. New title:    7.5.4 Internet Access or Not  // Emil 26 march
\label{sec:resultsPHR}
A possible addition to an interoperable EHR system is be to implement an interface for patients to access information stored in it through their Personal Health Records (PHR) from their home computers. This would be a useful way for patients to obtain the various medical records that are shown to schools, employers, or whoever they may need to share medical information with. Additional beneficial features could also be implemented into the health records to extend its functionality with self-care functionality and allow patients to carry out preliminary test before visiting their Health Care Provider (HCP). If PHRs are made available on the Internet, then this becomes a very sensitive issue.

\newpage

\section{Conclusions}
\label{sec:Conclusions}

Creating an interoperable system is a big and complex process that involves many different stakeholders. The development of such a system depends not only on the users and developers but also legal and financial authorities. Knowledge and technology for creating such a system exists, the main problem is to overcome the organizational issues. One also needs to take into consideration the payback period of constructing an interoperable system and be prepared for unforeseen costs.

Due to the large number of stakeholders and the work flow implications, it is of paramount importance to take into account that any new system must support the work processes of Health Care Providers (HCPs), be reliable and accessible. Apart from carefully designing the system interfaces based on successful standards and Electronic Health Records (EHR) systems, standardized care plans should be established, to accommodate not only the interoperability issues but also streamlining the work and ensuring patient safety and equal care.

%\newglossaryentry{top level interface}{name={top level interface}, description={format of communication between regions and nations}, plural={ top level interfaces}}

In order to accomplish secure, interoperable sharing of EHRs, the format of communication between regions and nations needs to be defined by standards. These may be developed at a regional level to fit the local needs but in order to be truly usable for large scale applications they should be developed at a global level. National stakeholders have to make educated decisions on which standards to use, possibly working together to merge the existing ones into a new set of standards that everyone uses, each standard complementing the other.

For the vision to come true, evidence for the socio-economic gains must be determined and the goals of each individual effort must be feasible in terms of law, technical solutions, and organization. Currently, there seem to be no single
organization willing to step forward and lead the development, possibly because of funding, power, and legal interpretation issues. Different organizations will have to work together backed by politicians. Initiatives like the recent G.E.-Microsoft Venture~\cite{Bits} are risky if not HCPs and politicians are on board.

In summation, the challenges of creating an EHR system are not technical in nature. It is certainly a daunting technical task but the technology and expertise exists to make a system like this. The problem is largely a socio-economic one and the social, political, and economic factors need to be better understood if we are to accelerate the development towards a utopian system and successfully deploy continually improved EHR systems in the future.

%Working with change and development regarding health care the process is usually time consuming and needs to be structured and planned carefully. 

\begin{comment}
These are the topics that we think might be important in the conclusion:
•	Cost
•	Efficiency
•	The people involved
•	Solution aspects (7.2.1 in the report)
•	Aspects regarding the future, the timeline of the project etc. 
•	Complex problem
\end{comment}


\newpage
\printglossaries
\newpage

\begin{appendix}
\end{appendix}



\bibliographystyle{unsrt} 
\bibliography{ourBib} 

\end{document}