pacs dbs

edckv permite modulizar la metadata dicom, tanto en el eje de una instancia como en el eje de las agrupaciones de series dentro de un estudio. Aprovechamos esta característica para definir un esquema de bases de datos distrbuido constando de dos niveles:

(1) db mysql study / series

La reconciliación de datos de pacientes entre estudios que divergen sobre este punto siempre fue un problema mayor para los pacs. Saltemamos esta complejidad en la fase de recepción de estudios nuevos. Cada uno contiene los datos del paciente propios sin reconciliación, como si no existiera el nivel paciente en la arquitectura DICOM.nada

La db mysql study / series está diseñada para responder a la selección de estudios y series, no a la visualización de las mismas. La tabla relacional series indica la articulación entre las mismas. Por ejemplo un KOS o un GPSP. Tambien contiene los datos SR, CDA y PDF, sin necesidad de visitar otra base de datos.

Para los otros casos se refiere a mount points donde se encuentra una base de datos sqlite con metadata y data propios de las imágenes del estudio.

(2) dbs sqlite (una para todas las instancias de una serie) guardadas cada una dentro de un archivo.

El formato de archivo de mysql (https://sqlite.org/fileformat2.html) está usado como protocolo para la comunicación entre servidor y clientes.

En el caso de series de menos de 64 MB, la data de los imágenes está incluido dentro del sqlite. De lo contrario, el sqlite hace referencia a los frames por su numero, que corresponde a archivos ubicados en el mismo directorio dónde se encuentra el sqlite.

Toda la arquitectura esta diseñada de tal forma que los request de parte del cliente esten siempre de tamaño razonable, sin necesidad de recortar información del lado servidor.

Usamos una reescritura rust de sqlite, escrita en el proyecto opensource Turso (https://turso.tech/blog/introducing-turso-in-the-browser), con implementaciones nativas servidor y browser mediante wasm. De esta forma se pasa dentro del protocolo el archivo sqlite y el browser lo interpreta para acceder a toda la metadata que necesita sin necesitar más conexiones al servidor.

Repartición de la información

+------------------------------------------+
| mysql (para selección)                   |
| E      study                             |
| ^      seriesof                          |
| S < G  substack (Group of frame numbers) |
+------------------------------------------+
                  |
       image series mount points 
                  |
                  +-----------------------------------+---------------+
                  v                                   |               |
+------------------------------------------+          v               v
| sqlite (para visualización)              |   large frames   atributos privados
| I      instance                          |
| ^      frameof                           |
| F      frame                             |
+------------------------------------------+

Principles of design

• No disambiguation at reception. Studies are stored with the exact metadata received. No patient or study reconciliation is performed at reception. Disambiguation is performed later, asynchronously, by specialized processes
• No data duplication. When a data deserves its own column in the table, it shall not be duplicated in the leftover column. For example, PatientID or StudyInstanceUID are found only in the respective columns.
• Propietary data is considered undesirable and kept in a leftover file. Except for series which consist of non image objects cda, pdf, gsps, kos, sr, ..., because there is no mount point for these objects
• everything is kept in explicit endian
• everything is kept charset in UTF-8, ready for web use. The attribute 00080005 is only indicative of which charset was used originally
• all the pixels are coded in HTJ2K.