Oui, il est dans la base de données et est accessible très rapide. Dans la base de données/schéma 'pacsdb', le nom de la table est 'instance', le nom de la colonne est 'inst_attrs'. Très probablement, vous devrez faire un choix avec des jointures impliquant des tables d'étude et de séries, selon la façon dont vous recherchez/présentez vos données.
Maintenant, le problème est, inst_attrs est un BLOB avec des données binaires. A l'intérieur, vous devez rechercher la chaîne hexadécimale suivante (à partir de la syntaxe de transfert DICOM) 28 00 00 01 55 53 02 00 xx 00 Ici, 28 00 00 01 est en réalité hexadécimal pour l'étiquette (0028, 0100) (Bits alloués), 55 53 02 00 indique "Non signé court (US) 2 octets long", et après cela, il y a habituellement 10 00 pour 16 bits ou 08 00 pour les images 8 bits. Donc, vous n'avez vraiment besoin que de la valeur "xx" des octets ci-dessus. En fonction des outils d'accès à la base de données que vous utiliserez pour obtenir ces données, vous pouvez choisir la meilleure stratégie. Il peut s'agir d'une application web (.war) déployée à côté de dcm4chee, probablement juste un tas de jsp sera suffisant; Il peut s'agir d'une application java séparée ou même d'un .NET - l'outil de choix dépend vraiment de l'endroit et de ce dont vous avez besoin. Pour l'accès web, je préférerais faire un .ear complet avec un bean session sans état pour récupérer les données et une petite application web protégée par mot de passe pour présenter les données et fournir un accès JSON/WS depuis l'extérieur.
Update Voici un exemple de SQL (MySQL seulement) qui renvoie l'UID d'étude UID de série et les bits affectés comme 10 pour 16 bits et 08 pour les images de 8 bits:
SELECT study_iuid as StudyUID, series_iuid as SeriesUID,
SUBSTRING(HEX(inst_attrs),
LOCATE('2800000155530200',HEX(inst_attrs))+16
,2) as BitsAllocatedHex
FROM instance i JOIN series s ON i.series_fk=s.pk
JOIN study st ON s.study_fk=st.pk