मेडिकल इमेजिंग ट्रांसफर: संपूर्ण तकनीकी गाइड

DPDP Act 2023 के अंतर्गत स्वास्थ्य डेटा "संवेदनशील व्यक्तिगत डेटा" की श्रेणी में आता है — और मेडिकल इमेजिंग फ़ाइलें इसी श्रेणी की सबसे बड़ी और सबसे संवेदनशील फ़ाइलें हैं। एक कार्डियक CT स्कैन 500 MB से 2 GB तक हो सकता है, पूरी स्लाइड पैथोलॉजी इमेज 4 GB तक, और fMRI शोध डेटासेट एक मरीज के लिए 40 GB तक पहुंच सकता है। इन्हें सही ढंग से ट्रांसफर न करना न केवल नियामक उल्लंघन है, बल्कि मरीज की देखभाल को भी खतरे में डालता है।

DICOM, NIFTI और आप वास्तव में क्या स्थानांतरित कर रहे हैं

ट्रांसफर विधि चुनने से पहले फ़ॉर्मेट समझें। DICOM (Digital Imaging and Communications in Medicine) पिक्सेल डेटा को मेटाडेटा टैग के साथ लपेटता है — मरीज का नाम (0010,0010) में, स्टडी UID (0020,000D) में, modality (0008,0060) में। एक सामान्य MRI स्टडी सैकड़ों .dcm फ़ाइलों का फ़ोल्डर होती है, जिसमें प्रत्येक फ़ाइल एक slice होती है। NIFTI (.nii या .nii.gz) न्यूरोइमेजिंग शोध का फ़ॉर्मेट है जो पूरे volume को एक फ़ाइल में पैक करता है।

सामान्य आकार:

• चेस्ट X-ray: 10-30 MB
• हेड CT: 50-200 MB
• एब्डोमिनल MRI: 300 MB-1 GB
• कार्डियक MRI: 500 MB-2 GB
• पूरी स्लाइड पैथोलॉजी (.svs, .ndpi): 1-4 GB प्रति स्लाइड
• fMRI टास्क रन: 500 MB-2 GB; पूरी स्टडी: 10-40 GB

अपने ट्रांसफर टूल को सबसे बड़ी फ़ाइल के अनुसार चुनें, औसत के अनुसार नहीं।

DICOMweb: आधुनिक वायर प्रोटोकॉल

DICOMweb, DICOM PS3.18 में परिभाषित, पुराने DIMSE प्रोटोकॉल को HTTP से बदलता है। तीन मुख्य सेवाएं:

• STOW-RS — /studies पर multipart/related body POST करके DICOM instances स्टोर करना।
• WADO-RS — GET /studies/{StudyInstanceUID} से डेटा प्राप्त करना।
• QIDO-RS — query parameters से studies और series खोजना।

DICOMweb TLS 1.3 पर चलता है और OAuth 2.0 bearer tokens के साथ अच्छी तरह काम करता है। Orthanc, dcm4chee, और Ambra Health जैसे आधुनिक PACS इसे support करते हैं। यदि दोनों अस्पताल प्रणालियां DICOMweb का उपयोग करती हैं, तो आपको अलग ट्रांसफर टूल की जरूरत नहीं — बस एक configured gateway चाहिए।

जब DICOMweb उपलब्ध न हो

अधिकांश वास्तविक ट्रांसफर उन प्रणालियों के बीच होते हैं जो gateway share नहीं करतीं। एक community hospital ट्रॉमा स्कैन tertiary center को भेजता है। मरीज अपना बाहर का MRI specialist के पास लाता है। ऐसे मामलों में:

1. SFTP (RFC 4253 with OpenSSH) — ज्ञात endpoints के बीच scheduled transfers के लिए विश्वसनीय।
2. IHE XDS-I.b — cross-enterprise imaging के लिए interoperability profile, Carequality जैसे HIEs द्वारा उपयोग।
3. Web-based encrypted upload — one-off या ad-hoc transfers के लिए व्यावहारिक विकल्प, खासकर जब मरीज शामिल हो।
4. Physical media — IHE PDI profile वाली जली CD अभी भी मौजूद है, हालांकि धीरे-धीरे कम हो रही है।

ट्रांसफर से पहले De-Identification

DICOM headers PHI से भरे होते हैं। DICOM Standard PS3.15 Annex E de-identification के लिए Basic Profile परिभाषित करता है जिसमें 400+ tags हटाने, बदलने या खाली करने की सूची है। DicomAnonymizer, CTP, और dcm4che का dcmdeid इसे implement करते हैं। सामान्य गलतियां:

• pixel data में burned-in annotations छोड़ना — इसके लिए OCR-and-redaction चाहिए, सिर्फ header बदलाव नहीं।
• (0009,xxxx) ranges में private tags भूलना जहां vendors scanner serial numbers छुपाते हैं।
• Study Instance UID रखना, जो attacker के पास original होने पर re-linking की अनुमति देता है।

CERT-In के दिशानिर्देशों और DPDP Act 2023 के अनुपालन में, शोध डेटा के लिए de-identification के साथ TLS 1.3 और AES-256-GCM at rest baseline है।

Compression, Transfer Syntax और Bandwidth

DICOM फ़ाइलें uncompressed (Implicit VR Little Endian) या JPEG 2000 Lossless (1.2.840.10008.1.2.4.90), JPEG-LS, या RLE के साथ स्टोर की जा सकती हैं। CT डेटा पर lossless compression 50-60% बचाता है। Lossy compression एक medicolegal minefield है — कई radiology practices इसे diagnostic use के लिए पूरी तरह प्रतिबंधित करती हैं।

100 Mbps symmetric link पर 2 GB cardiac MRI को लगभग 3 मिनट लगते हैं। 10 Mbps upload वाली site पर 30 मिनट। अपनी timeline तय करें — या ऐसा ट्रांसफर service उपयोग करें जो disconnect पर resume करे।

Patient-Controlled Transfers

एक बढ़ता workflow: मरीज specialist के कार्यालय में बैठकर USB stick या patient portal login देता है। Data Protection Board of India के अंतर्गत DPDP Act 2023 मरीजों को अपने स्वास्थ्य डेटा पर सहमति देने और वापस लेने का अधिकार देता है।

इस pathway के लिए ऐसी transfer विधि चाहिए जो non-technical मरीज उपयोग कर सके। एक web form जहां वे फ़ाइलें drop करें, passphrase के साथ client-side encrypt करें, और clinic को passphrase अलग से भेजें — यह काम करता है। HexaTransfer इस pattern में fit बैठता है — client-side AES-256-GCM, shareable link, passphrase out-of-band। hexatransfer.com पर try करें — free, no account, 10 GB max।

Teleradiology के लिए Chain of Custody

Teleradiology की देखभाल ऐसे transfer pipelines पर निर्भर करती है जिन्हें auditors घंटे-दर-घंटे trace करते हैं। आवश्यक बातें:

• SHA-256 hash sending PACS पर logged और reading station पर verified।
• Timestamped event log जिसमें accession number और reading radiologist ID शामिल।
• Transfer logs की retention state medical record laws द्वारा निर्दिष्ट अवधि के लिए — अक्सर मरीज की last visit से 7-10 साल, pediatric records के लिए और लंबा।
• Receipt confirmation के बाद transfer staging area की automatic purge।

MeitY के IT Act के अंतर्गत electronic health records को उचित audit trail के साथ maintain करना अनिवार्य है।

Web Transfers की 10 GB सीमा को संभालना

अधिकांश web-based transfer services individual transfers को 2-10 GB पर cap करती हैं। HexaTransfer 10 GB free में no account के साथ उपलब्ध है।

सीमा से ऊपर के transfers के लिए विकल्प:

• Logical bundles में विभाजन — एक visit, एक modality, एक series प्रति transfer।
• Physical shipping — AWS Snowball Edge 80 TB रखता है; encrypted LUKS या VeraCrypt drive के साथ courier ad-hoc के लिए काम करता है।
• Dedicated link — Direct Connect, ExpressRoute, या hospital VPN बार-बार के high-volume flows के लिए।

Timeline का वादा करने से पहले अपनी सीमा जानें।

PACS के साथ Integration बिना Reads को बाधित किए

एक नियम: radiologist की worklist न तोड़ें। यदि आपका transfer workflow PACS को touch करता है, तो staging node (Orthanc या dcm4chee DICOM router के रूप में) के माध्यम से route करें ताकि production PACS केवल validated studies प्राप्त करे। Incoming transfers को एक distinctive AE title से tag करें।

Outbound transfers के लिए, PACS में one-click "Send to External" action जो आपके transfer tool पर route करता है, radiologist को encryption workflow से बाहर रखता है — जो वे चाहते हैं।

Verification और Handoff

हर transfer के बाद verify करें:

1. File count मिलान (.dcm files या NIFTI volumes की संख्या)।
2. Archive का SHA-256 sender और receiver दोनों पर मेल खाता हो।
3. कम से कम एक image receiving viewer में खुले।
4. Metadata corrupt न हुई हो — patient name, study date, और accession number readable हों।

Transfer record में verification log करें। "हमने भेजा" कोई बचाव नहीं है; "हमने भेजा और byte-level integrity की पुष्टि की" है। मेडिकल इमेजिंग ट्रांसफर सिर्फ bytes नहीं — यह एक diagnostic record है जिस पर किसी की देखभाल निर्भर है, कभी-कभी मिनटों के भीतर।

अपनी healthcare imaging transfer workflow को सही ढंग से स्थापित करने के लिए hexatransfer.com पर जाएं।