Volume 42, Issue 6

The implementation of next-generation sequencing (NGS) in a clinical diagnostic setting opens vast opportunities through the ability to sequence all genes contributing to a certain morbidity simultaneously at a cost and speed that is superior to traditional sequencing approaches. On the other hand, the practical implementation of NGS in a clinical diagnostic setting involves a variety of new challenges, which need to be overcome. Among these are the generation, analysis and storage of unprecedented amounts of data, strict control of sequencing performance, validation of results, interpretation of detected variants and reporting. In the following sections, key aspects of data management and integration will be discussed. In particular, issues of data storage, data analysis using in-house IT infrastructure vs. data analysis employing cloud computing and the need for data integration from different sources will be covered.

The implementation of next-generation sequencing (NGS) in a clinical diagnostic setting opens vast opportunities through the ability to sequence all genes contributing to a certain morbidity simultaneously at a cost and speed that is superior to traditional sequencing approaches. On the other hand, the practical implementation of NGS in a clinical diagnostic setting involves a variety of new challenges, which need to be overcome. Among these are the generation, analysis and storage of unprecedented amounts of data, strict control of sequencing performance, validation of results, interpretation of detected variants and reporting. In the following sections, key aspects of data management and integration will be discussed. In particular, issues of data storage, data analysis using in-house IT infrastructure vs. data analysis employing cloud computing and the need for data integration from different sources will be covered.

Continuous glucose monitoring (CGM) technology represents a valuable tool for diabetic patients to control and regulate their blood glucose (BG) levels and to reduce adverse metabolic states, for example, by defining glucose alarm thresholds that alert users if the glucose value crosses to an undesired range. Improvement of CGM technology is ongoing, but there are barriers which confine the usefulness of CGM systems. The utility is mainly defined by the operability of the specific device and also by the provided benefit of available CGM software solutions. In order to take best advantage of diabetes therapy, users should be adequately educated in how to use their CGM system and how to interpret the collected data. Different CGM software applications provide partially different CGM reports and statistics. The standardization of this information also would be conducive to the best possible diabetes management.

Continuous glucose monitoring (CGM) technology represents a valuable tool for diabetic patients to control and regulate their blood glucose (BG) levels and to reduce adverse metabolic states, for example, by defining glucose alarm thresholds that alert users if the glucose value crosses to an undesired range. Improvement of CGM technology is ongoing, but there are barriers which confine the usefulness of CGM systems. The utility is mainly defined by the operability of the specific device and also by the provided benefit of available CGM software solutions. In order to take best advantage of diabetes therapy, users should be adequately educated in how to use their CGM system and how to interpret the collected data. Different CGM software applications provide partially different CGM reports and statistics. The standardization of this information also would be conducive to the best possible diabetes management.

The term “direct-to-consumer testing” (DTCT) describes all kinds of laboratory testing performed without the inclusion of a laboratory professional. It is thus performed in a gray zone between healthcare and consumers. The high volume of DTCT data as well as the ostensible feasibility of long-term data storage challenge medical professionals and consumers. No standards have been developed so far for the long-term storage of DTCT data. Unlike tests used in traditional laboratory medicine, many DTCT tests lack medical usefulness. This article describes the current concepts of DTCT and gives recommendations for the long-term data storage of DTCT data depending on the purpose of DTCT, the volume of data obtained and the possible medical implications of the test results.

The term “direct-to-consumer testing” (DTCT) describes all kinds of laboratory testing performed without the inclusion of a laboratory professional. It is thus performed in a gray zone between healthcare and consumers. The high volume of DTCT data as well as the ostensible feasibility of long-term data storage challenge medical professionals and consumers. No standards have been developed so far for the long-term storage of DTCT data. Unlike tests used in traditional laboratory medicine, many DTCT tests lack medical usefulness. This article describes the current concepts of DTCT and gives recommendations for the long-term data storage of DTCT data depending on the purpose of DTCT, the volume of data obtained and the possible medical implications of the test results.

Background: Even though technology advances and laboratory tests have become commonplace, there is a multitude of sources for errors. Furthermore, as the new General Data Protection Regulation (GDPR) adds to the thicket of storage and deletion periods, strategies for the best approach have to be developed. Legal context and methods: On the one hand, this article discusses civil claims due to damages arising from false laboratory results. This is done by a de lege lata analysis of the central liability provisions in the respective fields. On the other hand, different storage periods and deletion obligations for data in clinical laboratory testing and the best way of handling them are analyzed. Results and conclusions: Depending on the cause of the error, there are several possible liable parties. The most advantageous claims for the patient are those against the manufacturer in case of a defective device as he is regularly strictly liable. But also other parties involved can face similar claims due to their own wrongdoing. Although there can be claims against multiple parties involved, a fair allocation of damages according to the areas of responsibility of every party can be achieved through recourse. Concerning storage and destruction obligations, first the applicable timeframes have to be identified. Compliance can then be achieved by the implementation of technical and organizational measures. In the event of data-protection misconduct, there is a risk of considerable fines.

Background: Even though technology advances and laboratory tests have become commonplace, there is a multitude of sources for errors. Furthermore, as the new General Data Protection Regulation (GDPR) adds to the thicket of storage and deletion periods, strategies for the best approach have to be developed. Legal context and methods: On the one hand, this article discusses civil claims due to damages arising from false laboratory results. This is done by a de lege lata analysis of the central liability provisions in the respective fields. On the other hand, different storage periods and deletion obligations for data in clinical laboratory testing and the best way of handling them are analyzed. Results and conclusions: Depending on the cause of the error, there are several possible liable parties. The most advantageous claims for the patient are those against the manufacturer in case of a defective device as he is regularly strictly liable. But also other parties involved can face similar claims due to their own wrongdoing. Although there can be claims against multiple parties involved, a fair allocation of damages according to the areas of responsibility of every party can be achieved through recourse. Concerning storage and destruction obligations, first the applicable timeframes have to be identified. Compliance can then be achieved by the implementation of technical and organizational measures. In the event of data-protection misconduct, there is a risk of considerable fines.

Laboratory data is a treasure chest for personalized medicine: it is – in general – electronically available, highly structured, quality controlled and indicative for many diseases. However, it is also a box with (probably more than) seven locks: laboratories use their own internal coding systems, results are reported in different languages (four official languages plus English with very distinct features in Switzerland), report formats are not uniform, standard nomenclature (e.g. Logical Observation Identifiers Names and Codes [LOINC]) is not routinely used and even these coding systems lack important information, including data, for example, about the specific “kit” used for testing or preanalytical procedures affecting the sample quality and result interpretability. Visualization of complex laboratory and reporting “-omics” data are additional challenges. Currently, there is no “passepartout” key for all these locks available, and also newer concepts such as Fast Health Interoperability Resources (FHIR) might not provide enough plasticity to unconditionally render laboratory data interoperable. In this short overview, we present current approaches in Switzerland with a specific focus on the exemplary Bernese implementations.

Laboratory data is a treasure chest for personalized medicine: it is – in general – electronically available, highly structured, quality controlled and indicative for many diseases. However, it is also a box with (probably more than) seven locks: laboratories use their own internal coding systems, results are reported in different languages (four official languages plus English with very distinct features in Switzerland), report formats are not uniform, standard nomenclature (e.g. Logical Observation Identifiers Names and Codes [LOINC]) is not routinely used and even these coding systems lack important information, including data, for example, about the specific “kit” used for testing or preanalytical procedures affecting the sample quality and result interpretability. Visualization of complex laboratory and reporting “-omics” data are additional challenges. Currently, there is no “passepartout” key for all these locks available, and also newer concepts such as Fast Health Interoperability Resources (FHIR) might not provide enough plasticity to unconditionally render laboratory data interoperable. In this short overview, we present current approaches in Switzerland with a specific focus on the exemplary Bernese implementations.

With the implementation of the Austrian electronic health record (ELGA), laboratory results are formally standardized for the first time throughout Austria. The nomenclature of the lab analyses, their sequence and structure as well as the display of laboratory results are unified with ELGA. One of the most significant steps is using Logical Observation Identifiers Names and Codes (LOINC) as a reference terminology for lab analyses. Thereby laboratory results can be reused semantically interoperable all over Austria.

With the implementation of the Austrian electronic health record (ELGA), laboratory results are formally standardized for the first time throughout Austria. The nomenclature of the lab analyses, their sequence and structure as well as the display of laboratory results are unified with ELGA. One of the most significant steps is using Logical Observation Identifiers Names and Codes (LOINC) as a reference terminology for lab analyses. Thereby laboratory results can be reused semantically interoperable all over Austria.

Background Terminologies facilitate data exchange and enable laboratories to assist in patient care even if complex treatment pathways involve multiple stakeholders. This paper examines the three common terminologies Nomenclature for Properties and Units (NPU), Logical Observation Identifiers Names and Codes (LOINC), and SNOMED Clinical Terms (SNOMED CT). Methods The potential of each terminology to encode five exemplary laboratory results is assessed. The terminologies are evaluated according to scope, correctness, formal representations, and ease of use. Results NPU is based on metrological concepts with strict rules regarding the coding of the measurand and the result value. Clinically equivalent results are regularly mapped to the same code but there is little support to differentiate results from non-standardized measurements. LOINC encodes analyses as offered by the laboratory. Its large number of entries allows different mappings for the same analysis. SNOMED CT contains few analyses natively, but its formal composition mechanism allows representing measurements by post-coordinated expressions that are equivalent to LOINC codes. SNOMED CT’s strength lies in its support of many non-numerical result values. Implicit code hierarchies exist in NPU and LOINC. SNOMED CT has explicit, elaborate axioms that elucidate the meaning of its content. Its complexity and its license conditions, however, impede a more widespread use. Interpretive comments, a crucial part of laboratory results, are still difficult to encode with any of the terminologies. Conclusions All three terminologies have distinct potentials and limitations, but the approximation of SNOMED CT and LOINC suggests using them together. Terminologies need to be expanded to also cover interpretive comments.

Background Terminologies facilitate data exchange and enable laboratories to assist in patient care even if complex treatment pathways involve multiple stakeholders. This paper examines the three common terminologies Nomenclature for Properties and Units (NPU), Logical Observation Identifiers Names and Codes (LOINC), and SNOMED Clinical Terms (SNOMED CT). Methods The potential of each terminology to encode five exemplary laboratory results is assessed. The terminologies are evaluated according to scope, correctness, formal representations, and ease of use. Results NPU is based on metrological concepts with strict rules regarding the coding of the measurand and the result value. Clinically equivalent results are regularly mapped to the same code but there is little support to differentiate results from non-standardized measurements. LOINC encodes analyses as offered by the laboratory. Its large number of entries allows different mappings for the same analysis. SNOMED CT contains few analyses natively, but its formal composition mechanism allows representing measurements by post-coordinated expressions that are equivalent to LOINC codes. SNOMED CT’s strength lies in its support of many non-numerical result values. Implicit code hierarchies exist in NPU and LOINC. SNOMED CT has explicit, elaborate axioms that elucidate the meaning of its content. Its complexity and its license conditions, however, impede a more widespread use. Interpretive comments, a crucial part of laboratory results, are still difficult to encode with any of the terminologies. Conclusions All three terminologies have distinct potentials and limitations, but the approximation of SNOMED CT and LOINC suggests using them together. Terminologies need to be expanded to also cover interpretive comments.

Since the 1970s, computer supported data processing has been implemented in the laboratory and laboratory information systems (LIS) are being developed. In the following years, the programs were expanded and new laboratory requirements were inserted to the LIS. In the last few years, the requirements have grown more and more. The current tasks of the LIS are not only the management of laboratory requirements but also management of processes, data security and data transfer and they have become very important. Therefore, the current monolithic architecture of LIS has reached its limits. New methodologies like service oriented architecture, e.g. microservices, should be implemented. Thereby different specialized manufacturers provide software for one or a few tasks. These tasks can be more easily actualized like in the new field of agile software development. This new concept has been designed to provide updates and customer requirements according to its new organization structure in program development in a short time. For efficient data transfer, new interfaces and a standardization of master data like logical observation identifier names and codes (LOINC ® ) are advisable. With the growing data transfer, data security plays an increasingly important role. New concepts like blockchain programming (e.g. Medrec) are currently tested in (laboratory) medicine. To get an overview of the requirements of the own LIS, an Ishikawa diagram should be created. The main points of an Ishikawa diagram are shown and discussed. Based on the today-collected data, expert systems will be developed. For this kind of data mining, a structured data exchange is necessary.

Since the 1970s, computer supported data processing has been implemented in the laboratory and laboratory information systems (LIS) are being developed. In the following years, the programs were expanded and new laboratory requirements were inserted to the LIS. In the last few years, the requirements have grown more and more. The current tasks of the LIS are not only the management of laboratory requirements but also management of processes, data security and data transfer and they have become very important. Therefore, the current monolithic architecture of LIS has reached its limits. New methodologies like service oriented architecture, e.g. microservices, should be implemented. Thereby different specialized manufacturers provide software for one or a few tasks. These tasks can be more easily actualized like in the new field of agile software development. This new concept has been designed to provide updates and customer requirements according to its new organization structure in program development in a short time. For efficient data transfer, new interfaces and a standardization of master data like logical observation identifier names and codes (LOINC ® ) are advisable. With the growing data transfer, data security plays an increasingly important role. New concepts like blockchain programming (e.g. Medrec) are currently tested in (laboratory) medicine. To get an overview of the requirements of the own LIS, an Ishikawa diagram should be created. The main points of an Ishikawa diagram are shown and discussed. Based on the today-collected data, expert systems will be developed. For this kind of data mining, a structured data exchange is necessary.

Background: We developed two web-based applications called the “Percentiler” and “Flagger”. They use electronically sent data from the analysis of patient samples (medians in the Percentiler; % flagging in the Flagger). Through a graphical user interface, the applications allow on-line monitoring of the stability of analytical performance and flagging rate, both assessed against quality specifications. These are guided by biological variation (Percentiler) and effect of analytical instability on surrogate medical decisions (Flagger). Here, we report on the use of the applications. Methods: We constructed examples with combined observations to investigate whether the Flagger adequately translates the effect of analytical instability observed in the Percentiler, and whether the changes in the flagging rate tolerated by the proposed stability limits is realistic in combination with the analytical performance goals. Results: In general, the examples show that the most prominent flagging rates correlate well with the analytical stability and that the limits proposed for the Flagger are realistically linked to those of the Percentiler. They also show that for certain analytes the specifications for stable flagging rates can be restricted to 20% (relatively to the laboratory’s long-term flagging median) despite ambitious analytical performance goals, while for others they need to be expanded up to 70% in concordance with decreasing biological variation. Conclusions: The examples confirm that the changes in flagging rate is well related to the analytical variation, and that the proposed stability limits are fit-for-purpose. The combined observations may help individual laboratories to define realistic but ambitious performance specifications that apply for their local situation.

Background: We developed two web-based applications called the “Percentiler” and “Flagger”. They use electronically sent data from the analysis of patient samples (medians in the Percentiler; % flagging in the Flagger). Through a graphical user interface, the applications allow on-line monitoring of the stability of analytical performance and flagging rate, both assessed against quality specifications. These are guided by biological variation (Percentiler) and effect of analytical instability on surrogate medical decisions (Flagger). Here, we report on the use of the applications. Methods: We constructed examples with combined observations to investigate whether the Flagger adequately translates the effect of analytical instability observed in the Percentiler, and whether the changes in the flagging rate tolerated by the proposed stability limits is realistic in combination with the analytical performance goals. Results: In general, the examples show that the most prominent flagging rates correlate well with the analytical stability and that the limits proposed for the Flagger are realistically linked to those of the Percentiler. They also show that for certain analytes the specifications for stable flagging rates can be restricted to 20% (relatively to the laboratory’s long-term flagging median) despite ambitious analytical performance goals, while for others they need to be expanded up to 70% in concordance with decreasing biological variation. Conclusions: The examples confirm that the changes in flagging rate is well related to the analytical variation, and that the proposed stability limits are fit-for-purpose. The combined observations may help individual laboratories to define realistic but ambitious performance specifications that apply for their local situation.

External quality assurance (EQA) provides ongoing evaluation to verify that laboratory medicine results conform to quality standards expected for patient care. While attention has focused predominantly on test accuracy, the diagnostic phases, consisting of pre- and post-laboratory phases of testing, have thus far lagged in the development of an appropriate diagnostic-phase EQA program. One of the challenges faced by Australian EQA has been a lack of standardisation or “harmonisation” resulting from variations in reporting between different laboratory medicine providers. This may introduce interpretation errors and misunderstanding of results by clinicians, resulting in a threat to patient safety. While initiatives such as the Australian Pathology Information, Terminology and Units Standardisation (PITUS) program have produced Standards for Pathology Informatics in Australia (SPIA), conformity to these requires regular monitoring to maintain integrity of data between sending (laboratory medicine providers) and receiving (physicians, MyHealth Record, registries) organisations’ systems. The PITUS 16 Informatics EQA (IEQA) Project together with the Royal College of Pathologists of Australasia Quality Assurance Programs (RCPAQAP) has created a system to perform quality assurance on the electronic laboratory message when the laboratory sends a result back to the EQA provider. The purpose of this study was to perform a small scale pilot implementation of an IEQA protocol, which was performed to test the suitability of the system to check compliance of existing Health Level-7 (HL7 v2.4) reporting standards localised and constrained by the RCPA SPIA. Here, we present key milestones from the implementation, including: (1) software development, (2) installation, and verification of the system and communication services, (3) implementation of the IEQA program and compliance testing of the received HL7 v2.4 report messages, (4) compilation of a draft Informatics Program Survey Report for each laboratory and (5) review consisting of presentation of a report showing the compliance checking tool to each participating laboratory.

External quality assurance (EQA) provides ongoing evaluation to verify that laboratory medicine results conform to quality standards expected for patient care. While attention has focused predominantly on test accuracy, the diagnostic phases, consisting of pre- and post-laboratory phases of testing, have thus far lagged in the development of an appropriate diagnostic-phase EQA program. One of the challenges faced by Australian EQA has been a lack of standardisation or “harmonisation” resulting from variations in reporting between different laboratory medicine providers. This may introduce interpretation errors and misunderstanding of results by clinicians, resulting in a threat to patient safety. While initiatives such as the Australian Pathology Information, Terminology and Units Standardisation (PITUS) program have produced Standards for Pathology Informatics in Australia (SPIA), conformity to these requires regular monitoring to maintain integrity of data between sending (laboratory medicine providers) and receiving (physicians, MyHealth Record, registries) organisations’ systems. The PITUS 16 Informatics EQA (IEQA) Project together with the Royal College of Pathologists of Australasia Quality Assurance Programs (RCPAQAP) has created a system to perform quality assurance on the electronic laboratory message when the laboratory sends a result back to the EQA provider. The purpose of this study was to perform a small scale pilot implementation of an IEQA protocol, which was performed to test the suitability of the system to check compliance of existing Health Level-7 (HL7 v2.4) reporting standards localised and constrained by the RCPA SPIA. Here, we present key milestones from the implementation, including: (1) software development, (2) installation, and verification of the system and communication services, (3) implementation of the IEQA program and compliance testing of the received HL7 v2.4 report messages, (4) compilation of a draft Informatics Program Survey Report for each laboratory and (5) review consisting of presentation of a report showing the compliance checking tool to each participating laboratory.