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

هندسة تطبيقات الرعاية الصحية

مخططات وتدفقات البيانات: من المريض إلى التطبيق إلى واجهة برمجة تطبيقات Anpheros إلى سجل FHIR والخدمات الخارجية، ومن وكيل الذكاء الاصطناعي إلى واجهة برمجة تطبيقات السياق إلى البيانات المصرح بها.

Anpheros هي طبقة البيانات الطبية بين تطبيقك (أو وكيل الذكاء الاصطناعي) وسجل المريض. يحتفظ تطبيقك بواجهة المستخدم الخاصة به ومنطق العمل الخاص به؛ يعيش السجل الطبي والموافقة والمصدر والتدقيق في Anpheros ويتم الوصول إليها عبر واجهة برمجة تطبيقات واحدة.

  Your application, backend or AI agent
  (mobile app, web app, clinic system, lab system, LLM-based assistant)
                        │  HTTPS · API key (sk_test_ / sk_live_) or OAuth token (at_…)
                        ▼
  Anpheros Platform API
  ├─ /v1        simplified REST: patients, observations, conditions, medications,
  │             documents, timeline, provenance, context, labs, webhooks
  ├─ /fhir/R4   strict FHIR R4: 26 resource types, search, history, transactions,
  │             $everything, $summary (IPS), $validate
  └─ /oauth     OAuth 2.1 + PKCE, SMART on FHIR, OpenID Connect
                        │  every request: project isolation · scopes · rate limits
                        ▼
  One FHIR R4 record per patient
  ├─ versions of every resource (history)   ├─ Provenance for every write
  ├─ Consent resources for every grant      └─ access log visible to the patient
                        │
                        ▼
  Events out: signed webhooks to your server (ids only, never clinical content)

وجهة نظر المريض: من الشخص إلى الخدمات الخارجية

Patient
   ↓   uses an app, chooses what to share, sees every access
Healthcare application          Anpheros Daily, or your own app
   ↓   REST v1 / FHIR R4 over HTTPS, API key or OAuth token
Anpheros API
   ↓   isolation, scopes, idempotency, provenance
FHIR medical data               the patient's record: 26 resource types, every version kept
   ↓   only what the patient allowed, only for as long as allowed
External healthcare services    laboratories (lab import), clinics (directory, acting-as),
                                other apps (OAuth / SMART), your backend (webhooks)

العرض من منظور الذكاء الاصطناعي: من الوكيل إلى البيانات المصرح بها

AI agent or LLM application     runs the model you choose — hosted or local
   ↓   POST /v1/context  {patient, task, question, budget_tokens}
Medical context API             plans which parts of the record matter, fits them into the budget,
   ↓                            labels every item with author type and source, records a manifest
Authorised medical data         only records the project created or the patient granted;
                                the read appears in the patient's access log

لا يتلقى النموذج بيانات الاعتماد أبدًا ولا يقوم باستدعاء Anpheros بنفسه؛ يطلب تطبيقك السياق ويقرر ما الذي يتم إرساله إلى النموذج. مثالان كاملان مع استدعاءات API: تطبيق رعاية صحية بالذكاء الاصطناعي في تطبيقات الرعاية الصحية بالذكاء الاصطناعي ووكيل موافق عليه في الوكلاء بالذكاء الاصطناعي والبيانات الطبية. التفاصيل: الوكلاء بالذكاء الاصطناعي والبيانات الطبية، تطبيقات LLM والبيانات الصحية.

السجل

لكل مريض سجل واحد يتكون من موارد FHIR R4: Observation للعلامات الحيوية ونتائج المختبر والأعراض وملخصات النشاط اليومي، Condition و EpisodeOfCare و MedicationStatement و MedicationAdministration و DocumentReference و Immunization و AllergyIntolerance وغيرها - 26 نوعًا في المجموع، مدرجة مباشرة في CapabilityStatement (GET /fhir/R4/metadata). لا يوجد مخطط خاص لتعلمه: واجهة برمجة تطبيقات REST هي عرض أبسط لنفس الموارد، بنفس المعرفات.

لا يتم الكتابة فوق أي شيء بصمت. كل تحديث ينشئ إصدارًا جديدًا (/fhir/R4/{type}/{id}/_history)، ويسجل كل إصدار المشروع الذي كتبه والمؤسسة التي تم الكتابة نيابة عنها.

طريقتان للدخول

لا يرى المشروع أبدًا مرضى مشروع آخر ما لم يمنح المريض الإذن بالوصول. يحصل كل مشروع على معرفه الخاص لنفس الشخص (معرفات مزدوجة)، لذلك لا يمكن ربط المعرفات عبر التطبيقات، والسجل خارج نطاق وصولك يجيب بـ 404، وليس 403 أبدًا.

بيئتان

بيئة الاختبار (sandbox) وبيئة الإنتاج (production) هما قاعدتا بيانات منفصلتان. مفتاح بيئة الاختبار (sk_test_) لا يمكنه الوصول فعليًا إلى مرضى حقيقيين؛ فكل مشروع في بيئة الاختبار يحصل على نسخته الخاصة من 30 مريضًا اصطناعيًا، يمكن تعديلها وإعادة تعيينها بحرية. مفاتيح بيئة الإنتاج (sk_live_) تُصدر للمنظمات المعتمدة.

تدفقات البيانات

تطبيقك يكتب. POST /v1/patients/{id}/observations باستخدام Idempotency-Key. يقوم النظام بتخزين Observation FHIR، ويكتب Provenance (نوع المؤلف: مريض، ممارس، جهاز، استيراد أو ذكاء اصطناعي)، ويسجل الوصول ويرسل خطاف ويب resource.created إلى نقاط النهاية المشتركة.

تطبيق آخر يقرأ بموافقة. يوافق المريض على ذلك في صفحة الموافقة المستضافة (/oauth/authorize)، ويختار السجل والمدة (30-365 يومًا). يقوم التطبيق بتبادل الرمز مقابل رموز الوصول ويقرأ فقط ما تسمح به النطاقات. يرى المريض التطبيق ونطاقاته وكل قراءة في سجل وصوله، ويمكنه إلغاؤها في أي وقت.

مختبر يقدم النتائج. POST /v1/patients/{id}/labs/import باستخدام تقرير CSV أو HL7 v2 ORU^R01 أو JSON؛ تصبح كل نتيجة Observation مختبرية برموز LOINC حيثما كانت معروفة، وإعادة إرسال نفس التقرير آمن.

نموذج ذكاء اصطناعي يحتاج إلى سياق. POST /v1/context يعيد الأجزاء ذات الصلة من السجل لمهمة معينة، ضمن ميزانية رموز الوصول، مع تسمية كل عنصر بمصدره؛ يتم تسجيل المكالمة بمعرف بيان. يعمل النموذج نفسه في المكان الذي تختاره.

أين يتناسب Anpheros مقارنة ببنائه بنفسك

ذات صلة

• ما هو Anpheros؟
• تطوير برمجيات الرعاية الصحية
• الواجهة الخلفية وقاعدة بيانات تطبيقات الرعاية الصحية
• بناء تطبيق رعاية صحية
• نموذج الموافقة والوصول
• الأمان والخصوصية ومكان إقامة البيانات

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