Healthcare relies on diagnostic tests to ensure greater safety, effectiveness and efficiency. Clinical laboratory tests are the diagnostic tests in heaviest demand in daily clinical practice and, in terms of their volume and diversity, account for the greatest amount of information included in patients’ clinical records  . The laboratories’ results are involved in 70% of clinical decisions  and their quality is the main factor directly affecting the quality of care  .
These days, clinical laboratory tests are basic elements underpinning such healthcare tasks as screening for illness, diagnosis, and monitoring of the response to treatments  . Due to its impact and scope, the use of software to manage laboratory tests, both for requesting tests and checking the results, has become a key part of the information and communication technologies (ICT) applied to healthcare systems; it is viewed by clinicians as one of the great potential healthcare benefits deriving from Electronic Health Records (EHRs)      .
In order to understand key features of the design and implementation of electronic laboratory test request systems, it is first necessary to summarise the complete process of requesting an analysis, which in general is shared by all the areas of expertise covered by the clinical laboratories, and the basic characteristics of laboratory information systems (LIS). This process, well known to clinical laboratory staff, should be borne in mind by all personnel, whether medical workers, managers or programmers, interested in developing and installing electronic request modules for analytical tests, in order to understand the requirements and foundations of the functional design of this type of computer application, as well as the implications of its integration into the EHR. Finally, to help with the fundamental transition from theory to practice, there will be a review of the elements that may prove crucial for success when it comes to implementing this type of module in clinical healthcare practice and getting it up and running.
2. Complete Process of Requesting an Analysis
The process of requesting an analysis is not simply a case of receiving the sample in the laboratory, processing it and issuing the result in question. The complete process runs from the moment the clinician decides to request a laboratory test until the patient is informed of the result. This complete process is split into three basic stages―pre-analysis, analysis and post-analysis―all three being the responsibility of the clinical laboratory (Figure 1). This process applies equally to all the specialities of clinical laboratories, i.e. areas that habitually fall under this heading (biochemistry, haematology, microbiology, immunology, genetics) but also histopathology laboratories, because the complete process of requesting analyses is common to all.
2.1. Pre-Analysis Phase
This phase starts at the moment the clinician decides that laboratory tests are required. At this initial moment, the format of the analysis request is crucial, whether it is paper-based or electronic, with its numerous variables (open request, preselected tests, grouping of tests, etc.). Electronic requests can provide significant improvements at this initial phase by enabling help tools to be used in the request (recommendations, clinical practice guides, information about previous results, etc.).
Once the request has been made, the process continues with the appropriate preparation of the patient for the study requested, the taking of samples, their appropriate collection, storage and transportation to the laboratory, where they are duly received. Once in the laboratory, the pre-analysis phase continues with verification that the samples needed for the studies requested have been received, are in an appropriate condition and have been correctly identified. After these preliminary yet fundamental checks, the process continues with the preparation of the sample for analysis and its distribution to the various work areas of laboratory, leading to the next phase in the process, the analysis itself, which may be automated or manual.
The pre-analysis process can be subdivided into two stages, the extra-laboratory pre-analysis, also known as the pre-pre-analysis, which runs from when the process is started until the sample is received by the laboratory and the intra-laboratory pre-analysis, which is strictly speaking the pre-analysis phase,
Figure 1. Complete process of a Laboratory request. Within the circles are the phases of the process that are assumed by the EHR after the Integration with the LIS.
from when the sample is received to when the analysis itself begins. For practical purposes, the term “pre-analysis phase” as used here refers to the whole pre-analysis process.
Nowadays the pre-analysis phase is the most critical phase in the performance of analyses. Its importance lies in the fact that: 1) It is usually the most time-consuming phase in the whole analysis process (e.g. transport of samples from outlying sampling centres to laboratories); 2) It is the phase involving the greatest number of people (e.g. clinicians, nurses, auxiliaries, couriers, etc.), most of whom are not members of the laboratory’s own staff; and 3) Multiple variables need to be controlled by rigorous quality protocols to ensure the quality of the final result (e.g. appropriate preparation of the patient, appropriate containers, storage and form of transport at the correct temperature and time, appropriate identification of the patient and samples, etc.). It is not surprising, therefore, that this is the phase in which most errors are likely to occur  .
Given the characteristic features of this phase, the use of ICT to develop electronic request modules has become one of the main tools for improving analytical quality and healthcare safety during the entire analytical process  .
2.2. Analysis Phase
This phase runs from the start of the analysis proper, whether by automated equipment or manually, until the result becomes available. This part of the process includes such quality control measures as the fine-tuning of reactants, methods and equipment, their calibration and checking, as well as the proper training of laboratory staff to ensure correct technical validation of the result.
This phase today prompts the fewest errors in the analytical process  , thanks to the progress made in recent years in managing the quality of clinical laboratories. Since this part of the analytical process is the one that has least connection to the EHR, it is not necessary to examine it in greater detail here.
2.3. Post-Analysis Phase
Once the technical validation has been carried out by the professional in charge of analysis, the result passes to what is known as medical validation. In this phase, the medical member of the clinical laboratory team evaluates the result obtained, not only from the technical but also from the clinical point of view (e.g. the match between the result and the patient’s pathology, comparison with previous results, discrepancies between related parameters, etc.)
Once the medical validation has been completed, the laboratory issues the results report. This report should be distributed appropriately so that it reaches the requesting physician without going astray and in the shortest time possible. The analysis request process does not end here, however, since another factor to be borne in mind is what information reaches the clinician and how it is to be interpreted. This means that until the result is interpreted by the clinician with the appropriate healthcare quality safeguards (e.g. interpretive comments, suggestions for new tests, etc.) in order to be able to inform the patient correctly, the complete process of analytical request cannot be regarded as completed.
The post-analysis process can also be subdivided into a post-analytical phase, from the moment the result becomes available until it is validated and edited, and a post-post-analytical phase, from the moment it is published, either on paper or electronically, up to the moment it reaches the clinician and is interpreted. As with the pre-analysis phase, here too a range of professionals are involved; this phase is the second most susceptible to error in the entire analytical process  . It is also therefore susceptible to improvement, and to this end ICT constitutes a significant potential advance for healthcare safety by substantially improving aspects such as turnaround time and reliable delivery of results.
3. The Laboratory Information System
Laboratory information systems (LIS) have been in a continuous state of evolution since the 1970s, as a means of responding to the complexity of the information?in terms of both volume and diversity?produced by clinical laboratories  . It is these systems that have underpinned the laboratories’ current levels of output, enabling them to increase both productivity and security by applying software tools to the complete analysis request process.
Current LIS centre on the database of patients, tests and results, with multiple modules available that add extra functions for managing the entire analytical process. The core tasks of LIS include recording requests, connecting with the various analytical systems or working areas for the subsequent sending of tests and receiving results, organising workflows within the laboratory and storing, validating, editing and distributing the results in the form of laboratory reports.
Apart from covering the basic functions of the analytical process, LIS contribute substantial improvements in a number of areas, including quality control (e.g. recording the results of quality control, using expert rules to identify deviations, conducting comparisons with current or earlier results, etc.), statistical processing (e.g. activity statistics, average population measures, process control indicators, trends in demand, etc.), economic management (e.g. monitoring reactant consumption, warehouse management, accountancy and invoicing tools, productivity analysis, etc.) and medical security (e.g. controlling samples by barcode or radiofrequency labels, computerisation of manual processes vulnerable to error such as the recording of demographic information or the transcription of results, old records and the complete traceability of the analytical process, etc.).
All these functionalities are applicable, with their own particular characteristics, to all the clinical laboratories’ areas of expertise. The systems are shared by the majority, with specific developments for particular areas such as microbiological cultures or the new molecular biology technologies. In the case of histopathology laboratories, LIS should also offer certain special features such as records of gross findings and the digital treatment of images  , but the general schema is the same.
Of all these possible functionalities of LIS, the least relevant to EHRs are those concerned exclusively with activities carried out within the laboratory, while the most relevant are those linked to pre-and post-analysis phases. LIS were initially developed as an isolated application, focussing on the handling of requests, samples and results in the laboratory. At first, the entering of requests was done manually, with subsequent developments to enable automatic reading of referral forms (e.g. Optical Mark Recognition-OMR forms), while the editing of reports was done on paper, with subsequent manual distribution, which improved later with remote printing and the sending of results by email. As ICT has advanced, LIS have evolved to incorporate improvements both at the pre-analysis level (e.g. electronic request modules for the remote requesting of analyses) and in the post-analysis phase (e.g. online access to results). These new developments have made a notable contribution to improving the security and productivity of clinical laboratories.
To a large extent, however, LIS functioned as “islands of information” because their design was fundamentally inward-looking and unconnected to other healthcare computer applications. The next step in the evolution of LIS therefore focused on their integration into external applications that, in many cases, were developed and implemented before the LIS but have nowadays become a routine part of healthcare activity. This integration started when LIS were connected to hospital information systems (HIS). This connection enabled a substantial improvement to patient security by using the record number as sole identifier, thus enabling the automatic capture of demographic information and a significant decrease in the number of manual inputting errors. At the same time, tools for storing and checking analysis results were developed for many HIS. This integration continued to advance in line with the installation of new models for centralised computer registration of patients at all levels of healthcare. However, these computerised records gave way to electronic patient records that, for the most part, reverted to being new “islands of information”, since there was a lack of information exchange between levels or centres.
The emergence of EHRs, in the sense of a unique and complete record of a patient’s healthcare and state of health, regardless of the healthcare level used, constitutes an authentic attempt to do away with these “islands of information”   and marks a turning point in the application of ICT in healthcare provision   . The key element to building bridges between information islands is the development of common healthcare IT standards. Data communication standards are sets of rules that allow disparate computer systems to exchange information without requiring custom programming for each new connection. Semantic interoperability is the key stone in the electronic health record communication, being necessary an adequate codification and structuring of the data. Widespread adoption of shared standards is necessary to overcome these barriers and permit the creation of clinical data-sharing networks that can build bridges between the various islands of information.
In this situation, the evolution of the EHR brings it into direct contact with the LIS in all aspects of the pre-and post-analysis phases, with various models of integration ranging from simple access from the EHR to modules for requesting and checking the results of the LIS, to installing modules in the EHR itself for conducting these tasks. This type of module, which in generic terms may be referred to as a laboratory test request module (LTM), has become an essential feature of the EHR  , bringing significant benefits to healthcare security and clinical laboratory efficiency (elimination of identification errors and the manual data entry of LIS, fewer pre-analytical errors, less repetition of tests due to duplication, drastic reductions in response times, vastly reduced incidence of results going astray, improvement in the continuity of healthcare between levels etc.). Furthermore, the use of LTM-type modules integrated into the EHR also entails significant advances with regard to the LabWeb-type LIS, enabling for example the incorporation of test results into the EHR with a link to the clinical context, facilitating the use of support tools for decision-making and data-mining, integration with other corporate applications (e.g. appointment modules, healthcare processes, etc.) and connecting with various LIS, something that proprietary LabWeb systems cannot do.
For the construction of an EHR there are multiple recommendations and standards that can be applied. The Technical Committee on Health Informatics “ISO TC 215” (www.iso.org) provides international technical specifications for EHRs (ISO 18308 Requirements for an electronic health record architecture). In addition, CEN/TC 251 ‘Health informatics’ is a Technical Committee specifically dedicated to the development and provision of European Standards ensuring interoperability of health information systems throughout Europe, with systematic harmonization with the international environment (www.cen.eu). CEN/TC 251 has developed standards as: EN13606 Electronic Health Record Communication, designed to achieve semantic interoperability in the electronic health record communication, EN 13940 System of concepts to support continuity of care, often referred to as ContSys, and EN 12967 Health informatics service architecture or HISA, a services standard for inter-system communication in a clinical information environment.
Other standards widely used in ICT applied to healthcare systems are: HL7 (www.hl7.org) a standardized messaging and text communications protocol between hospital and physician record systems, and between practice management systems, ASTM E2369-12 Standard Specification for Continuity of Care Record (www.astm.org) and DICOM an international communications protocol standard for representing and transmitting radiology (and other) image-based data (www.nema.org).
There are also open software initiatives as open EHR an open standard specification in health informatics that describes the management and storage, retrieval and exchange of health data in electronic health records (www.openehr.org).
4. Functional Design of a Laboratory Test Request Module
The first step in the functional design of a computer application should be to set the goals that need to be achieved, something that serves as a highly useful guide throughout the entire process of module creation. In the authors’ experience, the basic goals for an LTM should include concepts such as:
-The possibility of requesting laboratory tests in any area of the clinical laboratory’s expertise, and availability at all healthcare levels (primary care, specialist care, emergencies and hospitalisation).
-The request, taking of samples and checking results should be possible from any healthcare centre connected to the EHR.
-Total traceability of the process, from making the request to receiving the final result.
-It should be possible to store all the results provided by clinical laboratories in the EHR as minable data, including the relevant clinical event where applicable, for epidemiological and research purposes.
-The patient’s results record should be unique, regardless of the healthcare level requesting it and the clinical laboratory generating it.
-Giving patients the freedom to choose the clinical laboratory from the healthcare network that best fits their needs, regardless of where the laboratory test request originated.
-Respecting the functional autonomy of each laboratory to the full, regardless of the LIS used by each centre.
-”Smart” help tools for laboratory test requests.
Once the functional goals have been established, we can then specify the functional scope needed to equip the electronic request module with the resources necessary to achieve them. In this process the functional design needs to be capable of fulfilling all the goals that have been set.
For example, if the target is to integrate information from different laboratories into the same EHR and, in addition, make the analytical data susceptible to mining along with all the rest of the clinical information, tests and results should be stored in a dispersed way. Therefore, to enable laboratory data to be mined like any other clinical data it is important to rule out, as far as possible, the use of document repository-type solutions (e.g. PDF) and work with an electronic message system that treats the basic information fields of a laboratory test (sample, test, result, units, etc.) independently  . This model requires that all the information received by the EHR should have the same format, using structured data and the greatest possible degree of codification to facilitate mining.
When an LTM is to be installed in a relatively small healthcare environment, with few laboratories involved, the uniformity of information formats can be achieved by unifying the LIS and their databases. But this solution is not applicable when the objective is to install a request module in a geographical area that spans districts, regions or national boundaries and the intention is to respect each centre’s LIS. The recommended course in these cases is to establish a common language for transmitting information between the LTM and the LIS while respecting the individual language of each centre    (Figure 2). A
Figure 2. Common nomenclature as a bridge between local dialects (CEN/TC 251 “Health informatics”).
database with a shared nomenclature is therefore required that enables the tests of each LIS to be traced in order to translate the tests and results from the local “dialect” to the common language. This model of communication ensures maximum respect for the autonomy of each laboratory since, in their local domain, they can continue using their usual nomenclature and units, thus facilitating the installation of the LTM in a wide healthcare setting and across a range of suppliers.
A laboratory-test codification system needs to be used for this common language, ensuring that they are unequivocally identified    . To this end, three basic elements of each test need to be codified: the specimen, the test being requested and the measurement itself, with the format of the result and the unit employed for the report also being established. These basic codified data will ensure that a common language is available to request tests and receive results but, given that the LTM needs to integrate results from various laboratories, analytical methods also need to be codified in order to control the effect of variations due to the use of different methodologies on measurement of the same biological parameter.
A laboratory-test codification system needs to be used for this common language, ensuring that they are unequivocally identified. Some examples include: LOINC (http://www.loinc.org), IUPAC-IFCC (http://www.iupac.org/body/702), CUMUL (http://www.cumul.ch), CPT (www.ama-assn.org/go/cpt), SNOMED (http://www.ihtsdo.org), with LOINC and IUPAC-IFCC being the most popular at an international level. The selection of the appropriate coding model will depend, among other things, on the aims envisaged by the design of the LTM  . For example, there is a need to codify the methodologies, and not all these models meet this requirement adequately. Meanwhile, the clinical use of laboratory tests needs to be taken into account: when a clinician requests a laboratory test it is not usually interested, barring exceptional cases, in knowing the benchmark that was used for calibration purposes or whether the parameter was determined by one method or another. Against the backdrop of this dichotomy in the coding, one possible solution enabling exhaustive methodological information to be collected, without jeopardising the healthcare uses of the LTM, consists of using two levels of coding, one for the clinician and another for the laboratory. When choosing a coding model it is also necessary to take into account the fact that an LTM should ideally codify both the request and the report, something that certain coding systems are not designed for: most of them in fact focus on the coding of reports.
Evidently, therefore, the aims that should determine the choice of coding system are functional aims, and if the available coding methods fail to meet the requirements, the need to adapt or modify one of the existing models will have to be assessed, with a view to creating a new one that meets all needs. This solution which, a priori, may be regarded as ideal in terms of meeting functional de-sign requirements, needs to be carefully evaluated in the light of the work it en-tails. Current databases of coded laboratory tests easily exceed 50,000 entries and any coding group that is set up would not only need to work on coding current tests but also indefinitely respond to the new and incessant stream of coding needs generated by the inevitably innovative activities taking place in clinical laboratories.
An example of new coding for functional requirements is provided by the case of Andalusia where, parallel to the design and development of the LTM for its EHR, known as “Diraya”, a Nomenclature and Coding Group (Spanish initials: GNC) was set up  . After analysing the various models, this group chose to use the IUPAC-IFCC coding methodology   but creating its own codes, with specific rules for systematic nomenclature, so as to adapt the coding to the functional objectives of the Andalusian Public Health System’s LTM. The coding of laboratory tests that this working group is creating is the biggest systematic nomenclature of laboratory tests in Spanish in the world (www.juntadeandalucia.es/servicioandaluzdesalud/hrs3/gnc/). Its characteristics enable it to be used both for coding the tests that are requested and the tests that are reported, acting as the connection point for exchanging information between the LTM and the LIS.
Whatever the model, therefore, the choice of coding system represents an extremely important step in the functional design process of an LTM, because the choice will depend on the functional scope established for the exchange of information between the laboratories and the EHR.
Another fundamental element to be borne in mind in the functional design of the LTM is the design of the request flow, in other words the complete circuit of the electronic request from the moment it is submitted by the clinician to the moment the final result is received. This circuit needs to be well defined, because it reveals by whom and when the application is used, this being fundamental for the organisation of the whole circuit of requests, samples and results between clinicians and laboratories, with the additional involvement of patients. Given its overriding organisational importance in various healthcare settings, the request flow needs to be established by professionals with experience in clinical laboratories and acquaintance with normal healthcare procedures, both primary and specialist services.
Among the basic steps that need to monitored, the following should be borne in mind: 1-Submission of the request and appointment (if applicable); 2-Sample taking and delivery to the laboratory; 3-Reception of the electronic request and sample in the laboratory; 4-The start of result-sending as well as the final complete delivery; and 5-Reading of the report by the requesting physician.
All these steps of the LTM should be completely traceable (date, time, operator, unit, etc.), thereby helping to improve the patient’s healthcare security. This flow will also be the basis for designing a large section of the electronic communication system required by integration of the LTM with the LIS. This communication system should use an international standard, the most frequently used being HL7 in its various versions   .
As well as the basic request-flow items mentioned above, the LTM should also feature a user-friendly system of notifications such as an ability to track the status of requests, notifications of unfinished tasks (e.g. requests not yet extracted, results not yet read, etc.) and notifications or results that are out of range and/or with critical values   .
In short, the LTM should have an appropriate functional design that enables analyses to be requested, pre-analytical needs to be established, the taking of samples to be recorded, appropriate communication with the LIS to be established and results to be stored in such a way that the entire process is traceable. This module will need to be integrated into the EHR to enable the analytical results to be linked to the clinical episode that generated the request and all the information stored in the patient’s EHR    .
To conclude this by no means exhaustive review of the basic characteristics to be borne in mind for the functional design of an LTM, mention should be made of the need for computer applications that are additional or supplementary to the LTM. Among the potential parallel developments to the LTM, two may be regarded as basic for clinical laboratories: the configuration module for LIS-LTM integration and the communication-tracking module for LIS-LTM integration (Figure 3). Their characteristics and basic functions are set out below.
The module responsible for configuring the LIS-LTM configuration is the basic tool needed in order to set the parameters for connections between the various LIS and the EHR’s LTM. This configuration module also becomes a key element in facilitating the installation of an LTM because it enables clinical
Figure 3. LIS-LTM integration modules. Modules above the dotted line are the responsibility of the Healthcare provider and the ones below are the responsibility of the LIS provider.
laboratories to become involved in the management of the analytical module of the EHR. The basic functionalities of this type of configuration module need to include:
-Controlling the level of access to the LTM from the various healthcare centres in the laboratory’s influence area.
-Managing the range of services offered by the laboratory, with the possibility of offering different test batteries depending upon where the request originates from.
-Mapping the codes used in each LIS to identify the laboratory tests onto the codes of the LTM’s systematic nomenclature, the “shared language”.
-Establishing all the pre-analytical information needed for appropriate sampling (preparing the patient, container, identification, preservative, etc.), as well as all the analytical and post-analytical information about the range of services (area of the laboratory doing the test, person in charge, response time, samples archive, etc.)
This information should be differentiated for each of the laboratories that make up the system, thereby enabling the LTM to generate the appropriate pre-analysis and test for each patient bearing in mind the individual characteristics of the laboratory where the test is to be carried out, facilitating both the patients’ access to the various laboratories and their functional autonomy.
The other parallel development to the LTM that may prove highly useful is what is referred to above as the communication-tracking module for LIS-LTM integration. The basic function of this application is to track messages between the LIS and the LTM, with functional requirements that will depend on the connection capacity of each LIS with external applications such as the EHR. As mentioned above, this type of functionality is one of the most recent develop-mental strands of LIS since, while LIS are very powerful in terms of internal communications control (connections with analytical teams), they still have some way to go in terms of their connectivity with external applications   .
The basic mission of this type of module, which can be an external application or part of the LIS itself, is to supply the tools needed to exchange information between the LIS and the LTM, controlling the message system and supplying appropriate solutions to ensure that the inherent characteristics of the LTM’s functional design (e.g. database of tests, units used for the results, etc.) do not impair the internal functioning of each laboratory. This module becomes a fundamental tool in enabling the laboratory to maintain total control of the analytical process and ensures, not the release of results, but their real availability in the LTM’s windows.
It should now be evident that the functional design of an LTM encompasses a wide spectrum of computing requirements while simultaneously involving numerous professionals. Given the large number of participants (healthcare and laboratory professionals, LIS constructors, computer programmers, administration, etc.), it is highly advisable to establish at the outset, as precisely as possible, the various domains of responsibility corresponding to each of these agents. This precautionary measure will enable the appropriate people in charge to be easily identified throughout the LTM’s design and start-up for the development tasks and any troubleshooting that may arise.
To conclude this section it is only necessary to underline that the functional design of an LTM should ensure the arrival of electronic requests and their capture by the LIS, the tracking of the samples and their arrival in the laboratory as well as the sending of results and laboratory reports, guaranteeing that what the clinic sees on its screen is the same as what is seen in the laboratory  , with the entire analytical process being recorded in the relevant episode of the patient’s EHR.
5. Installation and Operation: From Theory to Practice
The development of a module of these characteristics requires years of work to guarantee that all the functionalities envisaged operate in an error-free way  , with the time needed to get it up and running varying in accordance with the size of the healthcare system in which it is being installed. In a large healthcare system such as the Andalusian Public Healthcare System for example (8.5 million inhabitants, 1500 primary healthcare centres, 44 hospitals and more than 60,000 healthcare professionals), functional design of the LTM in Andalusia’s EHR started in 2003 and the first operational version was installed in 2007 in primary healthcare. Subsequent installations were rolled out in A&E and external clinics, with the final installation in hospitals taking place at the end of 2014. Almost four years of work were therefore needed for the functional design and the first operational system, and another seven for the development and gradual installation needed to reach all levels of the healthcare system. Currently around 16,200 daily requests are processed, with an average of 13 tests asked for per request, generating roughly 550,000 results every day, since the average number of results per request is 35. Despite all this, a great deal of work remains to be done because, although all Andalusia’s clinical laboratories have a connection to the LTM, not all of them have it 100% installed at all their levels of healthcare. In addition, the speed of installation is affected by the progress made in coding, on the part of the GNC, of all the tests currently available in all the clinical laboratories’ areas of expertise.
Designing and putting an LTM into operation is therefore a task that requires considerable time and significant amounts of work and resources; consequently it is a task that must be tackled in such as a way as to guarantee, as far as possible, its success. The key factors set out below need to be taken into account in order to be able to secure the transition from theory to practice with the minimum of risk:
1-The first, which is fundamental, is to have the full commitment of the healthcare the transition from theory to practice in question. This type of project requires significant financial and human resources, not only for its design and installation, but also for its maintenance, development and improvement over the long term. This is something that must be accepted by the political authorities responsible, to avoid wasting various years’ work and millions of euros or, in the best-case scenario, not achieving the hoped-for results in terms of improvements to healthcare security and the efficiency of the healthcare system.
2-Another key element is the dedication of the operational personnel in charge, who, as indicated earlier, must be professionals experienced both in clinical laboratories and in provision at all levels of the healthcare system. This dedication entails not merely supplying programmers with ideas but also engaging in teamwork that lasts throughout the entire programming process, with the aim of testing and ensuring that all the operating features fulfil the functional targets originally set out. This joint work with the programmers is fundamental to ensure that the module satisfies functional expectations, because knowledge of the healthcare situation usually varies considerably and the only solution is to work as a team throughout the entire programming process if problems are to be avoided.
3-Once the development phase is over, an appropriate pilot phase prior to widespread implementation is essential for this type of application. This pilot phase should be overseen initially by the operational personnel in charge, since they are the ones that truly understand what is expected of the behaviour of a new module in healthcare practice. This exhaustive piloting is fundamental for ensuring that the laboratories receive a tool that delivers its functional design in an error-free way and adapts smoothly to normal healthcare activity. To guarantee the success of the project it is therefore indispensable to conduct in-depth testing of the new modules before their widespread installation. While it should be acknowledged that all applications are capable of improvement, what cannot be permitted is their installation with non-identified operating errors due to inadequate piloting; this is especially true given that its introduction will meet resistance to change, resistance that will easily spread if errors in its envisaged functional scope are detected. This point should also be taken on board by the political authorities in charge of the health system, because their timeframes, and the ones that are actually required, tend not to coincide.
4-Meanwhile, in the initial phases of installation the laboratories need to confirm that no significant changes are taking place in their activities  , and they should commit themselves to being responsible for installation at the local level. Laboratory professionals have to assume a leadership role in these developments, as the people who know the business best, and need to take responsibility for the whole analytical process, although the pre-and post-analysis phases are handled in computer settings that fall outside the LIS. It is important that they understand and agree that the LTM is like an extension of the clinical laboratory within the EHR, for which they need to accept that computerisation is not an end in itself, but a basic tool that enables the information they generate, in the form of analytical results, to be transformed into knowledge when it is integrated into the patients’ clinical context within the EHR.
5-Once the time comes to install the LTM in the healthcare system, all the professionals involved in using it should be properly informed and trained (e.g. doctors, nurses, etc.). It is not worth skimping on the time and resources devoted to this task because, without the collaboration of the clinical professionals, the LTM installation is bound to fail. There must be proper familiarity with their work in order to provide solutions to the problems that arise and to provide all the support needed in the most approachable, easy and rapid way. The changes in work flows and rhythms brought about by an LTM always generate resistance to the novelty, which can be overcome by emphasising the healthcare advantages (e.g. security, reliability, response times, etc.) of this type of module, as opposed to its potential problems, which commonly include a perception that electronic requests take longer than their paper-based equivalents. In any event, it is always advisable to start the installation in healthcare units that are more open to innovation and proceed progressively, while setting a deadline for the replacement of paper-based by electronic requests. These units later prove extremely useful in extending the installation by acting as the path-breakers for the others to follow.
6-Getting the LTM up and running also requires the support and involvement of the IT services at each centre, their collaboration playing an indispensable part in the final success of the project. First, they are a fundamental source of support in training the professionals and, secondly, they prove invaluable in resolving day-to-day IT problems such as those involving hardware, problems that tend to be traditional “allies” of resistance to change.
7-Finally, the clear and decisive commitment of the management of the healthcare centres and departments is a key factor for all the work to be undertaken. Once the installation process of the LTM is underway, it is crucial that they should accept its implementation as a non-negotiable goal of all the healthcare professionals involved, not only those in the laboratories, and that they should convey this goal to all the healthcare units.
These recommendations do not make the successful design and implementation of an LTM inevitable, but they do go a significant way to making it more likely. Although the use of electronic systems integration into the EHR represents a significant advance that can handle the huge amount of information generated in healthcare, also it has its problems (changes in workflows, costs of implementation and maintenance, security risk against unauthorized access and loss of data, etc.). Further studies are required to demonstrate the superiority of integrating electronic systems and evaluate the real improvement in health output following the implementation of EHR.