Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

एंफ़ेरोस अन्य FHIR सर्वर की तुलना में कैसा है

स्व-होस्टेड FHIR सर्वर, क्लाउड FHIR स्टोर, ओपन-सोर्स हेल्थकेयर प्लेटफ़ॉर्म और एंफ़ेरोस अगल-बगल: कौन पहुंच को अधिकृत करता है, सहमति, उत्पत्ति, निवास, मूल्य निर्धारण, और प्रत्येक कब सही विकल्प है।

FHIR बैकएंड चुनने वाली टीमें आमतौर पर चार तरह के विकल्पों पर विचार करती हैं: एक ओपन-सोर्स सर्वर जिसे वे स्वयं होस्ट करते हैं, एक क्लाउड प्रदाता से एक प्रबंधित FHIR स्टोर, एक होस्टेड संस्करण वाला ओपन-सोर्स हेल्थकेयर प्लेटफ़ॉर्म, या Anpheros जैसा एक प्रबंधित हेल्थकेयर डेटाबेस। यह गाइड बताता है कि प्रत्येक प्रकार किसमें अच्छा है और Anpheros कहाँ स्थित है, जो अक्टूबर 2026 तक सार्वजनिक दस्तावेज़ों पर आधारित है। यहाँ नामित किसी भी उत्पाद के लिए, उसके अपने दस्तावेज़ों की जाँच करें; सुविधाएँ बदलती रहती हैं।

चार प्रकार

	सेल्फ-होस्टेड FHIR सर्वर (जैसे HAPI FHIR)	क्लाउड FHIR स्टोर (जैसे Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake)	हेल्थकेयर प्लेटफ़ॉर्म (जैसे Medplum)	Anpheros
यह क्या है	एक FHIR सर्वर जिसे आप चलाते हैं	क्लाउड खाते के अंदर एक FHIR डेटा स्टोर	प्रमाणीकरण, वर्कफ़्लो और होस्टेड संस्करण के साथ एक FHIR-नेटिव एप्लिकेशन प्लेटफ़ॉर्म	एक प्रबंधित हेल्थकेयर डेटाबेस: प्रति रोगी FHIR R4 रिकॉर्ड, सहमति, API, ऑडिट
कौन एक्सेस अधिकृत करता है	आप इसके चारों ओर जो कुछ भी बनाते हैं	क्लाउड का IAM, प्रति प्रोजेक्ट या डेटासेट	प्लेटफ़ॉर्म की एक्सेस नीतियां, आपके द्वारा कॉन्फ़िगर की गई	रोगी (OAuth 2.1 सहमति) या संगठन (API कुंजी)
रोगी-सामना करने वाली सहमति और ऑडिट	नहीं	नहीं	इसकी नीति मॉडल के साथ बनाया जा सकता है	अंतर्निहित, रोगी को दिखाई देने वाला
हर राइट पर प्रोवेनेंस	यदि आप इसे जोड़ते हैं	यदि आप इसे जोड़ते हैं	FHIR द्वारा समर्थित; आप इसे लागू करते हैं	आवश्यक और स्वचालित
अनुप्रयोगों के बीच पहचानकर्ता अलगाव	नहीं	नहीं	नहीं	प्रति एप्लिकेशन जोड़ीदार आईडी
लैब आयात (HL7 v2)	अलग टूलिंग	आंशिक (कुछ स्टोर में v2 से FHIR मैपिंग)	आपके द्वारा लिखे गए इंटीग्रेशन	अंतर्निहित, एक अनुरोध
डेटा निवास	जहाँ भी आप इसे होस्ट करते हैं	प्रदाता द्वारा पेश किए जाने वाले क्षेत्र	होस्टिंग पर निर्भर करता है	केवल यूरोपीय संघ
मूल्य निर्धारण	आपका इंफ्रास्ट्रक्चर और समय	उपयोग-आधारित (अनुरोध, भंडारण)	प्रति योजना या सेल्फ-होस्टेड	प्रति संगठन, संग्रहीत रोगियों के अनुसार
किसके लिए सर्वश्रेष्ठ	सीखना, पूर्ण नियंत्रण, असामान्य डेटा मॉडल	उन टीमों के लिए जो पहले से ही उस क्लाउड में हैं जो स्वयं हेल्थकेयर लेयर का निर्माण करेंगी	उन टीमों के लिए जो एक ओपन कोडबेस पर निर्माण करना चाहते हैं और पूर्ण स्टैक का स्वामित्व चाहते हैं	उन टीमों के लिए जो हेल्थकेयर लेयर को पूरा करना चाहते हैं और उत्पाद को अपने काम के रूप में चाहते हैं

Google Cloud Healthcare API या एक प्रबंधित प्लेटफ़ॉर्म?

Google का उत्पाद शाब्दिक रूप से Cloud Healthcare API कहलाता है, इसलिए यह "healthcare API" के कई खोजों में सबसे पहले दिखाई देता है। यह आपके Google Cloud प्रोजेक्ट के अंदर एक क्लाउड FHIR स्टोर (साथ ही HL7 v2 और DICOM स्टोर) है: स्टोरेज, FHIR सर्च और IAM-आधारित एक्सेस, उपयोग के अनुसार बिल किया जाता है। बाकी आप बनाते हैं — रोगी-सामना करने वाली सहमति और ऑडिट, एप्लिकेशन अलगाव, लैब आयात, SDKs और परीक्षण डेटा के साथ एक सैंडबॉक्स। Anpheros उन हिस्सों को प्रदान करता है और EU में डेटा संग्रहीत करता है; यह आपको अपने स्वयं के क्लाउड खाते के अंदर एक FHIR स्टोर नहीं देता है। यह चुनें कि स्वास्थ्य सेवा परत का स्वामित्व किसके पास होना चाहिए: आपकी टीम (Cloud Healthcare API) या प्लेटफ़ॉर्म (Anpheros)।

ओपन-सोर्स FHIR सर्वर या प्रबंधित?

ओपन-सोर्स सर्वर जैसे HAPI FHIR कहीं भी चलाए जा सकते हैं (Docker इमेज उपलब्ध हैं) और वे आपके अपने प्रोफाइल और एक्सटेंशन के साथ पूर्ण FHIR विनिर्देश का समर्थन करते हैं। उत्पादन में एक को चलाने का मतलब है कि आपको डेटाबेस, अपग्रेड, सुरक्षा, बैकअप और एक्सेस लेयर को स्वयं संचालित करना होगा। एक प्रबंधित प्लेटफ़ॉर्म उस स्वतंत्रता का कुछ हिस्सा (Anpheros 26 संसाधन प्रकार संग्रहीत करता है) उसे न चलाने के बदले में देता है। यह देखने के लिए FHIR डेटाबेस स्कीमा देखें कि ऐसा सर्वर पर्दे के पीछे क्या संग्रहीत करता है।

जहाँ Anpheros सही विकल्प है

आप रोगियों, क्लीनिकों, प्रयोगशालाओं या AI के लिए एक उत्पाद बना रहे हैं, और आप रिकॉर्ड नहीं, बल्कि उत्पाद लिखना चाहते हैं।
रोगी की सहमति और एक ऑडिट जिसे रोगी पढ़ सकता है, आवश्यकताएं हैं, न कि "अच्छा है" (GDPR Article 9, EHDS)।
आपका डेटा यूरोपीय संघ में ही रहना चाहिए।
आप FHIR R4 के साथ-साथ एक सरल REST व्यू, SDKs और वेबहुक भी चाहते हैं, वह भी एक ही विक्रेता से।
आप एक सैंडबॉक्स में, यथार्थवादी सिंथेटिक रोगियों के साथ, मुफ्त में शुरुआत करना चाहते हैं, और बिना फिर से लिखे उत्पादन में जाना चाहते हैं।

जहाँ कोई दूसरा विकल्प बेहतर हो

आपको Anpheros द्वारा समर्थित 26 के अलावा अन्य FHIR संसाधन प्रकारों, प्रोफाइल या एक्सटेंशन की आवश्यकता है, या पूरी तरह से कस्टम डेटा मॉडल की आवश्यकता है: एक सेल्फ-होस्टेड सर्वर आपको वह स्वतंत्रता देता है।
आपके संगठन को अनुपालन कारणों से सब कुछ एक क्लाउड खाते के अंदर रखने की आवश्यकता है: एक क्लाउड FHIR स्टोर उस नीति के अनुकूल है।
आप प्राधिकरण सर्वर और UI घटकों सहित पूरे स्टैक का स्वामित्व और संशोधन करना चाहते हैं: एक ओपन-सोर्स प्लेटफ़ॉर्म इसके लिए डिज़ाइन किया गया है।
आपको आज EHR लॉन्च, बल्क डेटा एक्सपोर्ट या system/ स्कोप की आवश्यकता है: Anpheros अभी तक उन्हें प्रदान नहीं करता है (देखें SMART on FHIR के साथ रोगी सहमति कैसे लागू करें)।

निर्णय का एक उचित तरीका

आपके उत्पाद को स्वास्थ्य सेवा परत के जिन हिस्सों की आवश्यकता है, उनकी गणना करें: सहमति, उत्पत्ति, ऑडिट, पहचानकर्ता, लैब आयात, दस्तावेज़ भंडारण, निवास, और आपके द्वारा पसंद किए जाने वाले विकल्प पर प्रत्येक के निर्माण और रखरखाव के महीनों का अनुमान लगाएं। फिर इसकी तुलना उस उत्पाद कार्य से करें जिसमें वे महीने जा सकते थे। Anpheros तब सही उत्तर है जब दूसरा नंबर बड़ा हो।