PACS system architecture data

The most important point that differentiates PACS from other medical information systems such as HIS and LIS is: massive data storage. Reasonable design of PACS data storage structure is the key to successful construction of PACS. A large hospital has a large number of modernized large-scale medical imaging equipment, the amount of data generated by the daily imaging examination up to about 4 GB (uncompressed raw data), the total amount of data for a year is about 1,200 GB, and with the rapid development of the hospital's business and the introduction of new imaging equipment, this amount of data may further increase. In addition, how to improve the efficiency of online data random access is also a very critical issue.

For this reason, existing PACS medical imaging information system providers mostly adopt the hierarchical storage (HSM) strategy, which divides PACS storage into two levels of structure: online storage and offline storage. Two different performance storage media are used to fulfill the requirements of high capacity and high efficiency respectively. Low-speed ultra-large capacity storage devices (offline storage servers) are used for permanent storage; high-speed storage devices (SAN) are used for online data storage to ensure extremely efficient access to online data. For more than 2 years of historical data saved in the offline storage device, the online storage device only save the last three years of data. DICOM files are medical files that are stored according to the DICOM standard.

DICOM files consist of multiple datasets. A dataset represents the relevant attributes of a real-world information object, such as patient name, gender, height and weight. A data set consists of data elements that contain the values of the attributes of the encoded information objects and are uniquely identified by data element tags. Data elements have three structures, two of which have a type representation VR (the presence or absence of which is determined by the transport syntax) and differ in the way their length is expressed, and one of which does not include a type representation. The type representation specifies what type of data is stored in the data element, and is a string of length 2. For example, a data element with a VR of FL indicates that the type of data stored in the data element is floating point. All data elements contain a label, a value length, and a data value body.

The label is a 16-bit unsigned integer pair, in sequential order including the group number and element number. Data elements in a dataset shall be organized in increasing order of the data element tag number and shall appear at most once in a dataset.

The value length is a 16- or 32-bit (depending on explicit VR or implicit VR) unsigned integer that indicates the length of the exact data value, recorded by the number of bytes (which is even). This length does not include the data element label, VR, or value length fields.

The data value body indicates the value of the data element, whose length is an even number of bytes, and the data type of this field is explicitly defined by the VR of the data element. The data element field consists of three public *** fields and one optional field. Take the mainstream SUPER PACS system in the current Guangdong market as an example.

The current SUPER PACS system database*** has 36 tables, which are categorized by purpose: public, digital film room-specific, radiology-specific, ultrasound-specific, and remote-specific tables. Among them, the four main tables that play a key role are Patient, Study, Series and Image.

The Patient table is used to store the basic information of the patient, and the application scope involves all the subsystems of SUPER PACS; the Study table is used to store the examination information of the patient, and the application scope involves all the subsystems of SUPER PACS; the Series table is used for the generation of the sequence table of the image, and the application scope involves SUPERPACSR DICOM radiology system; Image table is used to keep system image records.

The relationship between the database tables is shown on the right: