dataesr/scientific-paragraphs-categorization huggingface dataset:
In this section, you will learn more about these aspects of data integrity. Object identity originates from object-oriented programming and means that an object has an existence that is independent of its value. Thus, two objects may look the same, i. e. , they have the same value, but can still be different. Applying this to the representation of entity types in a database leads to the requirement that the representation of every entity must be uniquely identifiable. In a health information system, this is especially important for entity types such as "patient" and "case," but also for "finding," "order," and all other entity types (Sect. 3. 2. 3). This identity is needed, since all data need to be assigned to a specific patient and their cases. For example, if application components exchange information on the patient entity "Mr.
Since PIN and CIN are assigned during patient admission, only one admission has to be performed and only one PIN has to be assigned to patients during their visit, regardless of which ward they are treated on. For example, Mr. Russo was assigned a PIN (and CIN) when he was first admitted to Ploetzberg Hospital. This PIN will now be used whenever Mr. Russo is admitted to this hospital again. This works well if there is exactly one dedicated application system supporting patient admission, namely the patient administration system. The patient administration system must have direct access to a database that holds data allowing the reidentification of all past patients and cases in the hospital. To have this MPI as part of the patient administration system is an obvious choice. MPI are also required for patient identification in HIS which cover more than one health care facility.
Without object identity, there is no referential integrity, and without referential integrity, results cannot be related back to the correct patient. Therefore, without the correct usage of the PIN and CIN, the pure installation of technical means such as communication networks and computer systems is practically useless, as the precondition for data integrity is not met. Object integrity and referential integrity form two elements of data integrity. The third element we want to look at is data consistency. Data consistency means that copies of data on the same entity are identical. In health information systems architectures with many different application systems, the application systems often use the same data on patients and thus store them redundantly in their own database systems. This means that there are copies of data (e.
g. , of patient name, patient diagnosis, laboratory findings) that represent the same information about one particular entity. We call these copies of the same data "duplicates. " Obviously, these duplicates are supposed to be identical in all application systems where they are stored. In this case, we denote these duplicates as consistent. If the data are not identical and thus represent contradictory information, we call the duplicates inconsistent. Transaction management tries to make sure that data are and stay consistent-we then talk of replicates, meaning that copies of data are automatically held consistent. In health information systems having only one application system with only one database system, no redundant data exist, as all data are the so-called unicums-they only exist once.
In doing so, we concentrate on the computer-based part of health information systems. Architectural styles at the logical tool layer of the computer-based part of health information systems are characterized by the • number of databases being used to store data (especially patient-related data), • number of application systems used to support the functions, • number of different application software products used to install the application components and the number of vendors of these products, and • patterns of communication links between the application components used. These facets will be introduced as semantic dimensions which can be used to categorize hospital information systems' architectures.
DB 1 Architecture If a health information system (or its sub-information system) comprises only one database to store all patient-related data, we call this a DB 1 architecture (Fig. 3. 24). This single database system is often called the central database system for this (sub-)information system. The precondition for the DB 1 architecture (also: central architecture) is that all application systems store their data only in the central database and that this database is open for accessing and storing data there. There are two ways for realizing this style: • The application software products of the application systems originate from the same vendor who designed the database, they are all self-developed by a health care facility, or they have been developed particularly for this health care facility.
DB n Architecture In health information systems based on commercial software components from several different vendors, we can usually find DB n architectures (also: distributed architecture). This means that several application components store data on certain entity types persistently and contain their own database systems. Figure  3. 22 presents this style. As a consequence of this style, patient-related data must be stored redundantly in different application components. For example, data on the entity types "patient" and "case" may be stored in different application components, such as the patient administration system, LIS, and RIS. In this architecture, great emphasis must therefore be placed on the consistency of redundant data (Sect. 3. 8. 1). For example, the architecture must define which system is the responsible source for which data elements.
It may be useful to state, for example, that data on patient and case may be created and changed only by the patient administration system (however, the other components may locally store and use a copy of these data). We will discuss these topics in more detail in Sect. 3  Fig. 3. 22 DB n style with multiple application systems, each with its own database system, using 3LGM 2 symbols. The cloud in the center indicates that some as yet unknown means is needed to link the components It is quite obvious that in DB n architectures consistency of redundant data can only be achieved if the application systems are able to communicate with one another, i. e. , they must be interoperable. We will discuss interoperability of application systems in more detail in Sect. 3. 7. 1.
Mixed DB 1 /DB n Architectures In practice, you will hardly find health information systems with a pure DB 1 style. Even if one central application component with the central database has been installed in order to support the functions, it is hardly possible to stop implementation of further application components; and those application systems will usually come with their own databases. Hence, even if a considerable part of these health information systems is DB 1 styled, they are in sum actually DB n styled. Similarly, even DB n styled health information systems contain sub-information systems which are DB 1 styled. We will refer to the mixed style by the string "DB 1 /DB n ".
Number of Application Systems: Monolithic vs. Modular In the simplest case, the overall health information system consists of only one computer-based application system which supports most of the functions. This application system would then look like the one rock on which the whole hospital rests. Respective health information systems are commonly called monolithic. We will refer to this style by the string "AC 1 ". Of course, this application component contains the central database and AC 1 correlates with DB 1. A graphical representation of such a (DB 1 , AC 1 ) architecture is presented in Fig. 3. 23. Especially in large health care facilities such as university medical centers or even in home settings, however, one application component is usually not sufficient to support the different functions.
Radiology Information System Patient Administration System Laboratory Information System Fig. 3. 24 (DB 1 , AC n ) architecture with multiple application systems, using 3LGM 2 symbols. Only one application system (in the center) contains a database system However, modular architectures can still be DB 1 architectures: For example, the RIS, the LIS, and the patient administration system are connected to a certain application system which shares one single database management (Fig. 3. 24). The application system in the middle may be an open platform (Sect. 3. 9. 3). Such (sub-) information systems can be described by (DB 1 , AC n ). Anyhow, there is still widespread use of a combination of many application components and many databases, i. e. , of (DB n , AC n ) architectures, as in Fig. 3. 22.
Links are needed only between the application systems and the communication server. The number of links that must be managed can consequently be low-ideally, only n links exist for n application systems. We call this style star architecture and denote it as CP 1. Figure  3. 26 presents a (DB n , AC n , V n , CP 1 ) architecture. Note that star architectures do not necessarily contain communication servers, as the center of the star may also be an application system with a central database. Consequently, (DB 1 , AC n ) architectures will also be CP 1 architectures. Furthermore, we may call a service-oriented architecture (SOA) Fig. 3. 26 (DB n , AC n , V n , CP 1 ) architecture with multiple application systems connected by a specific application component, using 3LGM 2 symbols. This representation is also called a "star" architectural style with one application component serving as a broker or as a service bus a CP 1 architecture as well.
Syntactic Interoperability An application system is syntactically interoperable if it is technically interoperable and additionally uses a predefined structure for the exchanged messages. Thus, when technically exchanging a data file, string, or stream, specific data elements can be identified, such as beginning and end of a message or of message segments containing data on certain entity types such as "patient," "case," or "finding. " Syntactically interoperable application systems are thus able to obtain information from received messages-exchanged data becomes machine-readable. A quite simple approach to structure exchanged data are data formats such as CSV (comma-separated values) or XML. However, these formats cannot support syntactic interoperability by themselves, as they need additional agreements or rules, for example, on where to find the patient's name or birthdate in the given dataset.
Communication standards such as Health Level 7 Version 2 (HL7 V2), DICOM, and Health Level 7 Clinical Document Architecture (HL7 CDA) provide a data or document format together with clear rules on where to find which data element. Thus, they support syntactic interoperability. All these communication standards are presented in more detail in the next sections. For example, the patient administration system is syntactically interoperable if it is technically interoperable and can use HL7 V2, specifically the message type "administrative admission. " Thereby, the patient administration system can send Mr. Russo's administrative data to the RIS. If the RIS is syntactically interoperable as well, it will be able to incorporate these data in its database.
3. 7. 2. 9 and 3. 7. 2. 10. An information model describes the entity types and their relationships at a conceptual level, independent of any specific implementation or protocols. Information models are intended for designers. In contrast, a data model is defined at a lower level of abstraction. Data models are intended for implementers of databases. In addition to these two terminologies, also known as nomenclatures, there are numerous classifications in medicine. Classifications are mainly used for statistical purposes, for example, counting similar objects, or for grouping similar treatment cases together for billing purposes. Occasionally, however, they are also used to support semantic interoperability although they were not actually designed for this purpose. Some examples of classification systems used in health care are presented in Table  3.
e. , encapsuled, sharing of documents within and across different health care organizations. For the exchange of bio-signals and vital signs between point-of-care devices, the ISO/IEEE 11073 standard is available. openEHR focuses on the representation of clinical information in detailed clinical models and allows for the creation of a semantically fully defined EHR. SNOMED CT is a universal, multilingual clinical terminology for supporting semantic interoperability that includes more than one million relationships of different types between concepts. LOINC also supports semantic interoperability and is the most widely used standard for measurements and tests in health care, for example, laboratory tests. The Clinical Data Interchange Standards Consortium (CDISC) provides a number of standards, of which ODM-XML (Operational Data Model) is well-known for the representation of clinical research (trial) data and metadata, being widely used in electronic data capture (EDC) systems.
open Electronic Health Record (openEHR) openEHR (open Electronic Health Record) is an open standard specification which focuses on the standardized representation of clinical information in EHRs. It has been maintained by the openEHR Foundation since the early 2000s and supports semantic and syntactic interoperability. The specification follows a detailed (maximum) clinical information modeling approach and provides a formalism-the archetype definition language (ADL)to define archetypes as the basic building blocks representing clinical concepts. Furthermore, it includes the archetype query language (AQL), which-while syntactically similar to the ubiquitous SQL-operates on clinical concepts andunlike SQL-requires no knowledge of the persistence data structures (e. g. , database schemata). openEHR follows a two-layer modeling paradigm, fundamentally separating clinical content from technical details.
Clinical Data Interchange Standards Consortium (CDISC) The Clinical Data Interchange Standards Consortium (CDISC) spans a wide variety of standards, which are mainly-but not exclusively-designed for and used in clinical studies and trials in the pharmaceutical industry. CDISC standards were developed in the late 1990s and are maintained by the non-profit Clinical Data Interchange Standards Consortium. CDISC standards are free to use and cover different domains and parts of the complete process to develop clinical products such as new drugs. The use of some of these standards is mandatory for reporting and submitting results from clinical trials to regulatory authorities, for example, to the FDA (U. S. Food and Drug Administration). Common CDISC standards include the "foundational standards," which cover all necessary processes within research studies.
Data Integration Data integration is achieved in integrated health information systems when data that have been recorded and stored once in one application component are made available in a coherent and uniform way wherever they are needed, i. e. , in other application components, without having to be reentered. Data integration has two effects: • Data on different entity types being recorded and stored in different application systems can be combined for joint analysis and use in one particular application system. • New data on entity types need to be recorded, changed, deleted, or otherwise edited just once-even if the data are to be used in several application components. In DB 1 architectures, i. e. , architectures with a central database, data integration is comparatively easy to achieve.
Open platforms are a technology that can be used to implement this even in (AC n , V n ) architectures (Sect. 3. 9. 3). In case of a decentralized DB n architecture, data integration and a uniform view on the data is more challenging. Transaction management and communication servers are integration technologies suitable to meet this challenge (Sects. 3. 9. 1 and 3. 9. 2). Data integration helps to increase data consistency (Sect. 3. 5) and to reduce unnecessary double data entry: Assume that Mr. Russo was treated in the cardiology department, and a detailed medical history was collected and entered into the MDMS. Now Mr. Russo's health is deteriorating dramatically, and he must be moved to the ICU of the same hospital. If the medical history needs to be documented again, in case the information from the cardiology department cannot be accessed, there would be no data integration.
Transaction Management Transaction management ensures that every update of correct data in one or more databases will lead to another state in which the data in these database(s) are still correct. This turns out to be not trivial, especially for complex update operations, the so-called transactions. It is even more complicated in settings of more than one database system, i. e. , in DB n architectures. Transaction management guarantees data integrity and especially data Consistency through Atomicity, Isolation, and Durability of any transaction (ACID conditions). Atomicity guarantees that either all of the tasks of a transaction are performed or none of them are; isolation makes intermediary updates of data inside the transaction invisible; and durability stands for persistence of the transaction's results.
The "2-phase commit protocol" was developed for transaction management in DB n architectures. Among other things, this protocol is intended to ensure data consistency in case of data redundancy. In the initial phase, it checks if the transaction can be carried out by all affected application systems. Only if the changes are possible everywhere, they are actually carried out in a second phase in all application systems. To carry out the protocol, the application systems must be tightly coupled by synchronous communication, and the database schemata of all involved database systems must be known. For an application system in a health information system, this means that an interface must be provided where both updates and the cancellation of these updates are possible. This is not the case for commercial application components available today.
Generally, the individual database schemata of each component are also not known. Due to these reasons, the 2-phase commit protocol to ensure data consistency has usually not yet been implemented within DB n architectures of health information systems. Nevertheless, to guarantee data consistency, the following more asynchronous approach is typically chosen within a health information system: For every redundantly stored entity type, one application component is determined as the primary application system for this entity type. Thus, data on entities of this type can only be inserted, deleted, or changed in this primary application system. For example, the patient administration system is typically the primary application system for the entity types "patient" and "case. " Consequently, data on patients and cases can be created, deleted, or changed only in the patient administration system.
Therefore, this application system is sometimes called the "leading system. " Transactions in a database of the primary application system are carried out without regard to whether the corresponding operations can also be (immediately) carried out in the databases of the other affected application components. Patient admission is thereby carried out through the patient administration system independent of, for example, what is going on in the RIS. It may happen that the RIS is not capable of inserting corresponding data on the patient or the case that were sent by the patient administration system into its database at the same point in time. The RIS is then obliged to catch up on database operations at a later point in time.
Some communication servers may also provide synchronous communication. For this, the sending application system will pause from the time that it sends a message to the time that it receives the respective answer. In this way, communication servers can be used to invoke services as described in Sect. 3. 9. 4 and to provide feature integration as well. In health information systems with DB n architecture and redundant data storage, the application components store the data needed for supporting their functions by themselves. This holds especially for data on the entity types "patient" and "case. " Consequently, the communication server is used to ensure that every application system will find these data in its database system whenever the data is needed without having to request this data from the patient administration system.
The patient administration system creates a message that indicates that Mr. Russo was just admitted to Ploetzberg Hospital (event called "A01" by HL7). This message includes data on the entity types "patient" and "case" using a predefined standard (such as HL7). 2. The patient administration system sends this message to the communication server. 3. The communication server multicasts this message to all application systems that may need data on the entity types "patient" and "case" during the Mr. Russo's stay (e. g. , CPOE system, EHRS, RIS). Usually, nearly all application systems of health information systems need this administrative data. 4. All application components receiving the message will store the data on the entity types "patient" and "case" for Mr. Russo in their own database system in order to have them available in case they are needed.
An application system is called open platform if it stores patient data based on open specifications and open information models and provides open Application Programming Interfaces (API) for storing and querying these data. "Open" in this context means that the specifications, information models, and interfaces are published and can be used by any vendor. An open platform follows the idea that both data and metadata are stored in a centralized database, with strict separation between application logic and data storage. The advantage of the open platform approach is that other application systems with different functionalities from different vendors can directly work on the same database (DB 1 architecture). This facilitates both data integrity (Sect. 3. 5) and data integration (Sect. 3. 8.
1) even in V n architectures. The interoperability standard openEHR (Sect. 3. 7. 2. 8) provides a universal, agreed-upon information model. Open platforms were first used in medical image archives and PACS, then typically called vendor-neutral archives (VNAs). For example, after admitting Mr. Russo to the cardiology ward, blood samples have to be analyzed at the laboratory and radiological images have to be taken. Using an open platform as in Fig. 3. 24, the LIS and the RIS would be able to access the same database as the patient administration system even if they are from different vendors. To support communication between open platforms and other application systems, standards such as HL7 FHIR, DICOM, or IHE profiles are used (Sect. 3. 7. 2). While an open platform may seem difficult to introduce in a long-grown environment of different application systems with their own proprietary information models, it reduces the ever-increasing cost of mappings on the communication server side whenever a new application system is introduced.