ORCA (Nichi-Rece) ইলেকট্রনিক মেডিক্যাল রেকর্ড নয় — ইঞ্জিনিয়ারের দৃষ্টিতে রেসেকন ও মেডিক্যাল সিস্টেমের গঠন
· Go Komura · স্বাস্থ্যসেবা IT, ORCA, ইলেকট্রনিক মেডিক্যাল রেকর্ড, রেসেকন, সিস্টেম ইন্টিগ্রেশন
«ইলেকট্রনিক মেডিক্যাল রেকর্ডের ORCA» কথা শুনেছেন? চিকিৎসা প্রতিষ্ঠানের সিস্টেম প্রজেক্টে নামটা নিশ্চিত উঠে, কিন্তু এই ডাকে ভুল আছে। ORCA (JMA Standard Receipt Software / 日医標準レセプトソフト) ইলেকট্রনিক মেডিক্যাল রেকর্ড নয়।
এই নিবন্ধ স্বাস্থ্যসেবা IT প্রজেক্টে প্রথমবার আসা ইঞ্জিনিয়ারদের জন্য, নিচের প্রশ্নের উত্তর দেওয়ার লক্ষ্যে।
- ORCA কী, চিকিৎসা প্রতিষ্ঠানের সিস্টেম গঠনে কোথায় দাঁড়ায়
- রেসেকন যে «রেসেপ্ট কাজ» সামলায়, সিস্টেম হিসেবে আসলে কী করে
- কোন প্রযুক্তিতে তৈরি, প্রকাশিত সোর্সে কী আছে
- WebORCA মাইগ্রেশনে কী বদলায়, ইন্টিগ্রেট করা পাশকে কী ধরে রাখতে হয়
লেখা সব প্রকাশিত প্রাইমারি সোর্সে। সোর্স কোড নিয়ে যা লেখা, তা অফিসিয়ালি প্রকাশিত Nichi-Rece মূল 5.2 সিরিজ সোর্স (2026 সালের 1 জুলাই প্রকাশিত স্ন্যাপশট, VERSION ফাইলে 5.2.0) ডাউনলোড করে যাচাইয়ের ফল।
সূচিপত্র
- আগে উপসংহার — ORCA «রেসেকন»
- রেসেপ্ট কাজ কী — সিস্টেম দৃষ্টিতে দ্রুত ধারণা
- চিকিৎসা প্রতিষ্ঠানের সিস্টেম গঠন — ORCA কোথায়
- ORCA প্রজেক্টের ইতিহাস ও লাইসেন্স
- টেকনোলজি স্ট্যাক — COBOL 4 মিলিয়ন লাইন আসলে গুনে দেখা
- সোর্স ট্রি ঘোরা — কোথায় কী আছে
- ইন্টিগ্রেশনের প্রবেশপথ — Nichi-Rece API, PushAPI, CLAIM
- WebORCA মাইগ্রেশনে কী বদলায়
- সারাংশ — ইঞ্জিনিয়ারের ধরে রাখার কথা
- তথ্যসূত্র
এই নিবন্ধের জ্ঞান মানচিত্র
ORCA (Nichi-Rece) ইলেকট্রনিক মেডিক্যাল রেকর্ড নয়, চিকিৎসা ফি হিসাব ও receipt তৈরির দায়িত্ব নেওয়া rececon, এবং ইলেকট্রনিক মেডিক্যাল রেকর্ডের সঙ্গে Nichi-Rece API দিয়ে যুক্ত হয়। Nichi-Rece-এর বিজনেস লজিক COBOL-এ লেখা, MONTSUQI (panda) নামের এক্সিকিউশন প্ল্যাটফর্মের উপর Java ক্লায়েন্ট monsiaj ও PostgreSQL-এর সঙ্গে মিলিয়ে চলে, স্ক্রিন ও API দুটোই একই LD সংজ্ঞা দিয়ে ডিসপ্যাচ হয়। বাইরের ইন্টিগ্রেশনের প্রবেশপথ মূলত JMA ওপেন সোর্স লাইসেন্সের অধীনে প্রকাশিত Nichi-Rece API ও PushAPI; দীর্ঘদিন চলা CLAIM-এর সাপোর্ট 2026 সালের মার্চে শেষ হয়েছে এবং Nichi-Rece API-তে মাইগ্রেশনই ভিত্তি হয়ে গেছে। এখন WebORCA ক্লাউড সংস্করণ ও অন-প্রিম সংস্করণে মাইগ্রেশনের সময়কাল, লিগ্যাসি (MONTSUQI সংস্করণ) পরিবেশ থেকে ধাপে ধাপে প্রতিস্থাপন চলছে, কিন্তু ভিতরে দুটোই একই Nichi-Rece।
flowchart LR
accTitle: ORCA (Nichi-Rece)-এর জ্ঞান মানচিত্র
accDescr: ORCA (Nichi-Rece) rececon হিসেবে ইলেকট্রনিক মেডিক্যাল রেকর্ডের সঙ্গে দায়িত্ব ভাগ করে, COBOL · MONTSUQI · PostgreSQL · monsiaj-এর টেকনোলজি স্ট্যাক ও LD সংজ্ঞা দিয়ে ডিসপ্যাচ, Nichi-Rece API · PushAPI · CLAIM নামের ইন্টিগ্রেশন মাধ্যমের বিবর্তন, WebORCA ক্লাউড সংস্করণ ও অন-প্রিম সংস্করণে মাইগ্রেশনের সম্পর্ক দেখানো চিত্র
orca_nichirese["ORCA (Nichi-Rece)"]
receipt_computer["rececon (রেসেপ্ট কম্পিউটার)"]
receipt["receipt (চিকিৎসা ফি বিবরণী)"]
electronic_medical_record["ইলেকট্রনিক মেডিক্যাল রেকর্ড (EMR)"]
orca_api["Nichi-Rece API"]
cobol["COBOL"]
montsuqi["MONTSUQI"]
postgresql["PostgreSQL"]
monsiaj["monsiaj"]
ld_definition["LD সংজ্ঞা"]
push_api["PushAPI"]
claim_protocol["CLAIM (চিকিৎসা তথ্য বিনিময় প্রোটোকল)"]
jma_opensource_license["JMA ওপেন সোর্স লাইসেন্স"]
weborca_cloud["WebORCA ক্লাউড সংস্করণ"]
weborca_onpremise["WebORCA অন-প্রিম সংস্করণ"]
legacy_nichirese_deployment["লিগ্যাসি (MONTSUQI সংস্করণ) পরিবেশ"]
orca_nichirese -->|"বাস্তবায়ন করে"| receipt_computer
receipt -->|"পূর্বশর্ত"| receipt_computer
electronic_medical_record -.->|"ব্যবহার করে"| orca_api
orca_nichirese -->|"ব্যবহার করে"| cobol
orca_nichirese -->|"ব্যবহার করে"| montsuqi
orca_nichirese -->|"ব্যবহার করে"| postgresql
orca_nichirese -->|"ব্যবহার করে"| monsiaj
montsuqi -->|"দিয়ে কনফিগার"| ld_definition
orca_api -->|"দিয়ে কনফিগার"| ld_definition
orca_api -->|"পূর্বশর্ত"| montsuqi
monsiaj -->|"পূর্বশর্ত"| montsuqi
orca_nichirese -->|"ব্যবহার করে"| orca_api
orca_nichirese -->|"ব্যবহার করে"| push_api
orca_api -->|"উত্তরসূরি"| claim_protocol
orca_nichirese -.->|"পূর্বশর্ত"| jma_opensource_license
weborca_cloud -->|"বাস্তবায়ন করে"| orca_nichirese
weborca_onpremise -->|"বাস্তবায়ন করে"| orca_nichirese
weborca_onpremise -->|"উত্তরসূরি"| legacy_nichirese_deployment
legacy_nichirese_deployment -->|"ব্যবহার করে"| montsuqi
চিত্রে, টানা রেখা সবসময় সত্য এমন সম্পর্ককে এবং ভাঙা রেখা শর্তসাপেক্ষ সম্পর্ককে নির্দেশ করে (শর্তগুলো বিস্তারিত পাতায় প্রতিটি সম্পর্কের ব্যাখ্যায় আছে)। সম্পর্কের সম্পূর্ণ তালিকা (মোট 19, প্রমাণ ও নিশ্চয়তার মাত্রাসহ) এবং প্রধান ধারণাগুলোর সংজ্ঞা জ্ঞান মানচিত্রের বিস্তারিত পাতায় সংগ্রহ করা আছে (জাপানি ভাষায়)। তথ্য: JSON-LD / Turtle
1. আগে উপসংহার — ORCA «রেসেকন»
ORCA প্রজেক্টের কেন্দ্র «JMA Standard Receipt Software / 日医標準レセプトソフト» (সংক্ষেপে Nichi-Rece / 日レセ) একটি রেসেকন (receipt computer / মেডিক্যাল বিলিং সিস্টেম)। রেসেকন চিকিৎসায় যা করা হয়েছে তা থেকে চিকিৎসা ফি হিসাব করে, রিভিউ ও পেমেন্ট সংস্থার কাছে জমা দেওয়া রেসেপ্ট (চিকিৎসা ফির বিবরণী) তৈরির ব্যবসায়িক সিস্টেম।
ইলেকট্রনিক মেডিক্যাল রেকর্ড ও রেসেকনের ভূমিকা স্পষ্ট ভাগ।
| দৃষ্টিকোণ | ইলেকট্রনিক মেডিক্যাল রেকর্ড | রেসেকন (ORCA / Nichi-Rece) |
|---|---|---|
| মূল উদ্দেশ্য | ক্লিনিক্যাল রেকর্ড তৈরি ও সংরক্ষণ | চিকিৎসা ফি হিসাব ও রেসেপ্ট তৈরি |
| মূল ব্যবহারকারী | চিকিৎসক, নার্স | মেডিক্যাল অ্যাফেয়ার্স (医事課), রিসেপশন স্টাফ |
| কেন্দ্রীয় ডেটা | ফাইন্ডিং, প্রগ্রেস, অর্ডার | রোগীর মূল তথ্য, ইনস্যুরেন্স, রোগনির্ণয়, চিকিৎসা কার্যক্রম, ফি পয়েন্ট |
| আইনি অবস্থান | ক্লিনিক্যাল রেকর্ড (কার্টে / カルテ) ইলেকট্রনিক সংরক্ষণ | দাবির কাজের সরঞ্জাম |
| প্রতিনিধিত্বকারী ইন্টিগ্রেশন | রেসেকন, ল্যাব ডিভাইস, ইমেজিং সিস্টেম | রিভিউ ও পেমেন্ট সংস্থা, অনলাইন যোগ্যতা যাচাই |
«ইলেকট্রনিক মেডিক্যাল রেকর্ডের ORCA» ডাকনাম জন্মেছে কারণ অনেক ইলেকট্রনিক মেডিক্যাল রেকর্ড পণ্য «বিলিং অংশ ORCA-এর সাথে ইন্টিগ্রেট» গঠন নিয়েছে। ইঞ্জিনিয়ার হিসেবে ORCA = দাবি-পাশের কোর, ইলেকট্রনিক মেডিক্যাল রেকর্ড = ক্লিনিক্যাল রেকর্ড-পাশ এই ভাগ শুরুতেই ধরলে পরের কথা সব গোছায়।
2. রেসেপ্ট কাজ কী — সিস্টেম দৃষ্টিতে দ্রুত ধারণা
রেসেকন কী সিস্টেম বুঝতে চিকিৎসা প্রতিষ্ঠানের আয়ের প্রবাহ জানাই দ্রুত পথ। জাপানের ইনস্যুরেন্স চিকিৎসায় রোগী কাউন্টারে সাধারণত 10 থেকে 30 শতাংশ দেন, বাকিটা চিকিৎসা প্রতিষ্ঠান রিভিউ ও পেমেন্ট সংস্থার (সামাজিক ইনস্যুরেন্স চিকিৎসা ফি পেমেন্ট ফান্ড, ন্যাশনাল হেলথ ইনস্যুরেন্স সংস্থাগুলো) কাছে মাসিক দাবি করে। সেই দাবির কাগজই রেসেপ্ট।
সিস্টেম হিসেবে রেসেকন নিচের মাসিক ব্যাচ চক্র ঘোরায়।
- দৈনিক: রিসেপশনে ইনস্যুরেন্স যোগ্যতা যাচাই, চিকিৎসা কার্যক্রম (কনসালটেশন, ল্যাব টেস্ট, ওষুধ, প্রসিডিউর…) ইনপুট, ফি পয়েন্ট তালিকা (点数表) অনুযায়ী অটো হিসাব করা কাউন্টার চার্জ দিয়ে অ্যাকাউন্টিং।
- মাসিক: এক মাসের চিকিৎসা কার্যক্রম রোগী × ইনস্যুরেন্স এককে জমা করে রেসেপ্ট তৈরি। জমার আগে ডেটা চেক (রোগনির্ণয় ও প্রেসক্রিপশনের মিল ইত্যাদি), ইলেকট্রনিক রেসেপ্ট (রেসে-ডেন ডেটা) হিসেবে জমা।
- পরের মাস থেকে: রিভিউতে ফেরত «henrei / 返戻» বা অ্যাসেসমেন্টে কাটা «satei / 査定» সামলিয়ে সংশোধন করে আবার দাবি।
এখানে জরুরি: ফি পয়েন্ট হিসাবের নিয়ম প্রতি দুই বছরের চিকিৎসা ফি সংশোধনে বদলায়। ফি পয়েন্ট মাস্টার, ওষুধের দাম, হিসাবের নিয়মের সংশোধন সফটওয়্যার না ধরলে চিকিৎসা প্রতিষ্ঠান ঠিকমতো দাবি করতে পারে না। রেসেকন সফটওয়্যারের আসল কঠিন কাজ UI বা স্কেল নয়, এই নিয়ম অনুসরণ কয়েক দশক ধরে চালিয়ে যাওয়া। পরে দেখা ORCA সোর্সে খোদাই করা সংশোধন ইতিহাস ঠিক সেই রেকর্ড।
3. চিকিৎসা প্রতিষ্ঠানের সিস্টেম গঠন — ORCA কোথায়
ক্লিনিকের সাধারণ গঠন ছবিতে আঁকলে ORCA (Nichi-Rece) প্রতিষ্ঠানের ভিতরের সিস্টেমের হাবের কাছাকাছি দাঁড়ায়।
flowchart LR
subgraph clinic["চিকিৎসা প্রতিষ্ঠানের ভিতরে"]
EMR["ইলেকট্রনিক মেডিক্যাল রেকর্ড<br/>ক্লিনিক্যাল রেকর্ড ও অর্ডার"]
RSV["রিসেপশন ও অ্যাপয়েন্টমেন্ট সিস্টেম"]
ONS["অনলাইন যোগ্যতা যাচাই টার্মিনাল"]
ORCA["ORCA / Nichi-Rece<br/>রেসেকন (চিকিৎসা ফি দাবি)"]
EMR -->|"Nichi-Rece API (HTTP)"| ORCA
RSV -->|"রিসেপশন ও অ্যাপয়েন্টমেন্ট ইন্টিগ্রেশন"| ORCA
ONS -->|"ইনস্যুরেন্স যোগ্যতার তথ্য"| ORCA
end
ORCA -->|"রেসেপ্ট (মাসিক দাবি)"| PAY["রিভিউ ও পেমেন্ট সংস্থা<br/>পেমেন্ট ফান্ড ও জাতীয় স্বাস্থ্য ইনস্যুরেন্স সংস্থা"]
লক্ষণীয় তিনটে।
- রোগীর মূল তথ্য ও ইনস্যুরেন্স তথ্যের মাস্টার ORCA পাশে থাকে এমন গঠন বেশি। ইলেকট্রনিক মেডিক্যাল রেকর্ড API দিয়ে পড়ে ও আপডেট করে। রোগী নম্বরের সিরিয়াল কে দেবে, সেটা ইন্টিগ্রেশন ডিজাইনের প্রথম ইস্যু।
- চিকিৎসা কার্যক্রম (কী করা হয়েছে) ইলেকট্রনিক মেডিক্যাল রেকর্ড থেকে ORCA-তে যায়, ORCA ফি পয়েন্ট হিসাব করে অ্যাকাউন্টিং ও দাবিতে নিয়ে যায়। ইলেকট্রনিক মেডিক্যাল রেকর্ড «অর্ডারের ভাষা», ORCA «ফি পয়েন্টের ভাষা»য় চিকিৎসা লেখে, তাই সেই রূপান্তর (চিকিৎসা কার্যক্রম কোড ম্যাপিং) ইন্টিগ্রেশনের আসল কঠিন জায়গা।
- মাসিক রেসেপ্ট জমা ORCA-এর কাজ। অর্থাৎ চিকিৎসা প্রতিষ্ঠানের আয় ORCA দিয়ে দাবি হয়। ইন্টিগ্রেশন ভুল ক্লিনিক্যাল রেকর্ড হারানো নয়, দাবির টাকার ভুল হিসেবে দেখা দেয় — এই টেনশনই এই ক্ষেত্রের বৈশিষ্ট্য।
4. ORCA প্রজেক্টের ইতিহাস ও লাইসেন্স
ORCA জাপান মেডিক্যাল অ্যাসোসিয়েশন (JMA / 日医)-এর প্রজেক্ট। 2001 সালের নভেম্বরের «JMA IT ঘোষণা»-তে জাপান মেডিক্যাল অ্যাসোসিয়েশন যে সফটওয়্যার বানায় তা ওপেন সোর্স হিসেবে প্রকাশের নীতি বলা হয়, তার কেন্দ্র হিসেবে তৈরি Nichi-Rece। 2002 থেকে চিকিৎসা মাঠে ব্যবহার শুরু, তারপর 20 বছরের বেশি ধরে ডেভেলপমেন্ট চলছে।
ইঞ্জিনিয়ারের দৃষ্টিতে বিশেষ: ব্যবসায়িক সিস্টেমের সোর্স কোড 20 বছরের বেশি প্রকাশিত হয়ে চলেছে।
- লাইসেন্স সোর্সের সাথে থাকা 日医オープンソース使用許諾契約 (JMA OpenSource License version 1.0)। GPL নয়, JMA-এর নিজস্ব চুক্তি; প্রোগ্রাম ব্যবহার (কপি, অভিযোজন, বিতরণ, পাবলিক ট্রান্সমিশনসহ) নন-এক্সক্লুসিভ ও বিনামূল্যে দেওয়া, পরিবর্তিত সংস্করণ বিতরণে একই শর্ত চাপানো — কপিলেফট-ধরনের গঠন। প্রযোজ্য আইন জাপানি আইন।
- আগে CVS রিপোজিটরি প্রকাশিত ছিল, কমার্শিয়াল সংস্করণ শুরুর সাথে CVS প্রাইভেট, এখন প্রতি মাসের 1 তারিখে আগের মাসের 1 তারিখের সোর্স tarball হিসেবে প্রকাশ। প্রকাশের লক্ষ্য মূল, আঞ্চলিক পাবলিক-এক্সপেন্স (地域公費), প্রকাশিত ফর্ম — এই তিন কম্পোনেন্ট; 5.0, 5.1, 5.2 সিরিজ পাশাপাশি প্রকাশিত।
- ডেভেলপমেন্ট ও সরবরাহের গঠনও আলাদা। সোর্সের সংশোধন ইতিহাস পড়লে শুরুতে NACL (Custom Software Development কন্ট্রাক্টর)-এর ইঞ্জিনিয়ার নাম, 2022-এর কাছ থেকে ORCAMO (জাপান মেডিক্যাল অ্যাসোসিয়েশন ORCA ম্যানেজমেন্ট অর্গানাইজেশন) নামে কমিট বদলায়। আশপাশের সার্ভিস (সাপোর্ট, প্যাকেজ, ম্যানুয়াল ইত্যাদি) কমার্শিয়াল সংস্করণ হিসেবে ORCA ম্যানেজমেন্ট অর্গানাইজেশন দেয়, ইনস্টল ও রক্ষণাবেক্ষণ সারা দেশের স্বীকৃত সাপোর্ট প্রোভাইডার সামলায় — এই ভাগের মডেল।
অর্থাৎ ORCA «ওপেন সোর্স, কিন্তু GitHub-ধরনের কমিউনিটি ডেভেলপমেন্ট নয়» সফটওয়্যার। সোর্স পড়া যায়, ফর্কও যায়, কিন্তু মূল ধারা এক সংস্থা ভেন্ডারের মতো এগিয়ে নিয়ে যায় — ভুল চলে না, নিয়ম অনুসরণ বাধ্যতামূলক স্বাস্থ্যসেবার ক্ষেত্র ভাবা যুক্তিসঙ্গত জায়গা।
5. টেকনোলজি স্ট্যাক — COBOL 4 মিলিয়ন লাইন আসলে গুনে দেখা
এই অধ্যায় থেকে বিশেষ নাম হঠাৎ বাড়ে, তাই আগে পরিভাষা টেবিল রাখি। পরের অধ্যায়ও এই টেবিল পাশে রেখে পড়ুন।
| নাম | কী | ভূমিকা |
|---|---|---|
| Nichi-Rece (日レセ) | JMA Standard Receipt Software (日医標準レセプトソフト)-এর সংক্ষেপ | ORCA প্রজেক্টের কেন্দ্র রেসেকন মূল |
| MONTSUQI | Linux-এ চলা ওপেন-সোর্স OLTP (OnLine Transaction Processing) মনিটর | Nichi-Rece-এর ব্যবসায়িক প্রোগ্রাম চালানোর এক্সিকিউশন প্ল্যাটফর্ম। স্ক্রিন ও API প্রবেশপথ একত্র করে |
| panda | MONTSUQI প্যাকেজ ও ইমপ্লিমেন্টেশনের নাম | বাস্তবে MONTSUQI-ই। INSTALL.ja-তে এই নামে আসে |
| monsiaj | Java ক্লায়েন্ট | সার্ভার থেকে স্ক্রিন ডেফিনিশন নিয়ে আঁকে, থিন ক্লায়েন্ট |
| MONPE | MONTSUQI Printing Environment-এর সংক্ষেপ | Nichi-Rece XML ফর্মের ডেভেলপমেন্ট ও প্রিন্ট টুল |
| LD ডেফিনিশন | lddef/-এর নিচের ডেফিনিশন ফাইল |
কোন স্ক্রিন, কোন API কোন COBOL প্রোগ্রাম সামলাবে তার ডিসপ্যাচ টেবিল |
| রেসে-ডেন ডেটা | ইলেকট্রনিক রেসেপ্টের ডেটা ফর্ম্যাট | রিভিউ ও পেমেন্ট সংস্থায় জমা মাসিক দাবির ডেটার আসল রূপ |
প্রকাশিত 5.2 সিরিজ সোর্সের INSTALL.ja-তে প্রয়োজনীয় সফটওয়্যার হিসেবে MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE ইত্যাদি সাজানো। গঠন সংক্ষেপে:
| লেয়ার | প্রযুক্তি | টীকা |
|---|---|---|
| OS | Linux (বর্তমানে Ubuntu-তে সরবরাহ) | JMA IT ঘোষণার সময় থেকে Linux ভিত্তি |
| ব্যবসায়িক লজিক | COBOL | ওপেন-সোর্স COBOL টুলচেইনে কম্পাইল |
| এক্সিকিউশন প্ল্যাটফর্ম | MONTSUQI (panda) | Nichi-Rece-এর জন্য গড়া OSS মিডলওয়্যার |
| ডেটাবেস | PostgreSQL | টেবিল ডেফিনিশন ডকুমেন্টও অফিসিয়ালি প্রকাশিত |
| ক্লায়েন্ট | monsiaj (Java) ইত্যাদি | স্ক্রিন ডেফিনিশন সার্ভার থেকে নেওয়া থিন ক্লায়েন্ট |
| ফর্ম | MONPE ইত্যাদি | রেসেপ্ট ইত্যাদি ফর্মের ডিজাইন ও আউটপুট |
কথায় স্কেল আসে না, তাই 5.2 সিরিজ স্ন্যাপশট (আনপ্যাকের পর প্রায় 8,200 ফাইল, 237MB) আসলে গুনে এই ফল।
| লক্ষ্য | পরিমাপ |
|---|---|
COBOL সোর্স (.CBL) |
1,754টা, মোট প্রায় 4.06 মিলিয়ন লাইন |
COPY ক্লজ (শেয়ারড ডেফিনিশন .INC) |
2,377টা |
ডেটা স্ট্রাকচার ডেফিনিশন (record/) |
প্রায় 1,240টা |
স্ক্রিন ডেফিনিশন (screen/) |
400-এর বেশি |
ফর্ম ডেফিনিশন (form/) |
600-এর বেশি |
DB টেবিল (LD ডেফিনিশন orcadb.inc-এ তালিকা) |
285 টেবিল |
ডেটাবেসের টেবিল নাম সোজা, পড়তে অভ্যস্ত হলে কাজ সোজা দেখা যায়। নামকরণে «ইংরেজি সংক্ষেপ» ও «জাপানি রোমাজি» মেশানো, তাই জাপানি অংশ একবার কানজিতে ফেরালে অর্থ ধরা যায়। মূল কয়েকটা:
| টেবিল নাম | নাম খোলা | বিষয় |
|---|---|---|
tbl_ptinf |
pt = patient, inf = information | রোগীর মূল তথ্য |
tbl_ptbyomei |
pt = patient + byomei = 病名 (বিয়োমেই, রোগনির্ণয়) | রোগীর রোগনির্ণয় |
tbl_uketuke |
uketuke = 受付 (উকেতসুকে, রিসেপশন) | রিসেপশন |
tbl_jyurrk |
jyurrk = 受療履歴 (জুরিওরিরেকি, চিকিৎসা ইতিহাস) সংকুচিত রূপ | চিকিৎসা ইতিহাস |
tbl_tensu |
tensu = 点数 (তেনসু, ফি পয়েন্ট) | ফি পয়েন্ট মাস্টার |
tbl_syskanri |
sys = system + kanri = 管理 (কানরি, ম্যানেজমেন্ট) | সিস্টেম ম্যানেজমেন্ট |
«রোগী, ইনস্যুরেন্স, রোগনির্ণয়, চিকিৎসা কার্যক্রম, ফি পয়েন্ট» — ১ অধ্যায়ের ভূমিকা ভাগ টেবিল গঠন হিসেবেই ইমপ্লিমেন্ট। টেবিল ডেফিনিশন ডকুমেন্ট অফিসিয়াল সাইটে প্রকাশিত, পড়তে দ্বিধা হলে সেখানে অফিসিয়াল নাম দেখুন।
আর্কিটেকচারের চাবিকাঠি MONTSUQI। Nichi-Rece-এর ভিতর: Java ক্লায়েন্ট (monsiaj) সার্ভার থেকে স্ক্রিন ডেফিনিশন নিয়ে দেখায়, ইনপুট সার্ভার-পাশের COBOL প্রোগ্রাম প্রসেস করে PostgreSQL পড়ে-লেখে — ক্লাসিক কেন্দ্রীভূত প্রসেসিং। কোন স্ক্রিন কোন COBOL প্রোগ্রামে যায়, lddef/ ডিরেক্টরির LD ডেফিনিশন ফাইলে ডিক্লারেটিভভাবে লেখা।
flowchart LR
CL["monsiaj<br/>Java ক্লায়েন্ট"] -->|"স্ক্রিন অপারেশন"| MW["MONTSUQI<br/>অ্যাপ্লিকেশন সার্ভার"]
API["ইন্টিগ্রেটিং সিস্টেম<br/>ইলেকট্রনিক মেডিক্যাল রেকর্ড ইত্যাদি"] -->|"Nichi-Rece API (HTTP)"| MW
MW -->|"lddef/*.ld ডেফিনিশন দিয়ে ডিসপ্যাচ"| AP["ব্যবসায়িক প্রোগ্রামসমূহ<br/>COBOL প্রায় 1,750টা"]
AP --> DB[("PostgreSQL<br/>285 টেবিল")]
আগ্রহের জায়গা: স্ক্রিন ডিসপ্যাচ ও API ডিসপ্যাচ একই LD ডেফিনিশন ফাইলে পাশাপাশি। অর্থাৎ Nichi-Rece API পরে জোড়া আলাদা সার্ভার নয়; ইন্টারঅ্যাকটিভ স্ক্রিনের একই ব্যবসায়িক প্রোগ্রাম প্ল্যাটফর্মের ওপর «স্ক্রিনের বদলে XML-এ কথা বলার প্রবেশপথ» যোগ করে ইমপ্লিমেন্ট। এই ডিজাইনের বিস্তার পরের কিস্তিতে।
«COBOL + বিশেষ মিডলওয়্যার + PostgreSQL» আধুনিক ওয়েব ডেভেলপমেন্টের অনুভূতি থেকে দূর মনে হয়। কিন্তু একটা COBOL প্রোগ্রামের হেডারে 2002 থেকে সংশোধন ইতিহাস কমেন্টে খোদাই, ইলেকট্রনিক প্রেসক্রিপশন (2022) বা My Number হেলথ ইনস্যুরেন্স কার্ড যোগ্যতা যাচাই (2024)-এর মতো সাম্প্রতিক নিয়মও — একই কোডবেস 20 বছরের বেশি সংশোধন ধরে চলেছে পড়া যায়। এই গঠন «পরিপক্ক হয়ে চলতে থাকা»-র জন্য অপ্টিমাইজের ফলও।
6. সোর্স ট্রি ঘোরা — কোথায় কী আছে
সোর্স পড়ার মানচিত্র হিসেবে টপ-লেভেলের মূল ডিরেক্টরি সাজাই।
| ডিরেক্টরি | বিষয় | কোথায় নজর |
|---|---|---|
cobol/ |
ব্যবসায়িক লজিক মূল। মডিউল অনুযায়ী 50-এর বেশি সাবডিরেক্টরি | প্রোগ্রাম হেডারের সংশোধন ইতিহাস নিয়ম সংশোধনের কালপঞ্জি |
lddef/ |
LD ডেফিনিশন। স্ক্রিন ও API-এর ডিসপ্যাচ টেবিল | সিস্টেমের «সূচিপত্র»। পুরো ছবি আগে এখান থেকে |
record/ |
ডেটা স্ট্রাকচার ডেফিনিশন (API-এর XML স্ট্রাকচারও এখানে) | রেসপন্স XML-এর ট্যাগ নাম record/-এর আইটেম নামই |
sql/ |
DB স্কিমা মাইগ্রেশন SQL (2.0 সিরিজ থেকে 5.2 সিরিজ, ভার্সন অনুযায়ী) | স্কিমার বিবর্তন = ফিচার যোগের ইতিহাস |
screen/ / form/ |
স্ক্রিন ডেফিনিশন, ফর্ম ডেফিনিশন | রেসেপ্ট, প্রেসক্রিপশন ইত্যাদি ফর্মের আসল রূপ |
doc/ |
লাইসেন্স (license.html) ইত্যাদি |
日医オープンソース使用許諾契約-এর পুরো লেখা |
মাঠের এক সতর্কতা। সোর্সের ক্যারেক্টার এনকোডিং EUC-JP (লাইসেন্স ডকুমেন্ট ISO-2022-JP)। আধুনিক এডিটরে খুললে মোজিবাকে হয়, তাই iconv -f EUC-JP -t UTF-8 দিয়ে পড়তে হয়। 2002-এর Linux পরিবেশের স্ট্যান্ডার্ড যেমন ছিল তেমন রাখা এক ধরনের টাইম ক্যাপসুল।
7. ইন্টিগ্রেশনের প্রবেশপথ — Nichi-Rece API, PushAPI, CLAIM
বাহিরের সিস্টেমের ইঞ্জিনিয়ার ORCA নিয়ে কাজ করতে গেলে প্রবেশপথ বাস্তবে তিনটে।
- Nichi-Rece API — এখনকার সুপারিশ। ইন্টিগ্রেটিং সিস্টেম HTTP-তে রিকোয়েস্ট পাঠিয়ে রোগীর তথ্য আনা, রিসেপশন, চিকিৎসা কার্যক্রম নিবন্ধন ইত্যাদি করে। রিড অপারেশন GET অথবা POST+XML, আপডেট POST+XML মূল। অফিসিয়াল সাইটে API স্পেক প্রকাশিত।
- PushAPI — Nichi-Rece পাশে ঘটা ইভেন্ট (ফর্ম প্রিন্ট নির্দেশ ইত্যাদি) ইন্টিগ্রেটিং সিস্টেমকে জানানোর ব্যবস্থা। পোলিং নয়, ইভেন্ট-ড্রিভেন স্ক্রিন সমন্বয় বানানো যায়।
- CLAIM — মেডিক্যাল তথ্য বিনিময়ের স্ট্যান্ডার্ড নিয়ম হিসেবে দীর্ঘকাল চলেছে, কিন্তু 2026 সালের মার্চে সাপোর্ট শেষ। সোর্সে এখনও CLAIM-জাতীয় প্রসেস আছে, তবে বিদ্যমান CLAIM ইন্টিগ্রেশন API-তে মাইগ্রেশন ধরে নেওয়া হয়েছে।
অর্থাৎ এখন থেকে ORCA ইন্টিগ্রেশন ডিজাইন করলে Nichi-Rece API একটাই পথ। আর আগেই বলা, API ইন্টারঅ্যাকটিভ স্ক্রিনের একই COBOL ব্যবসায়িক প্রোগ্রাম প্ল্যাটফর্মে ইমপ্লিমেন্ট, তাই «API-এর আচরণ বোঝা যায় না» হলে সোর্স পর্যন্ত নেমে যাচাই করা যায়। API-এর পুরো ছবি (অফিসিয়াল তালিকায় নেই এমন এন্ডপয়েন্টসহ) সোর্স থেকে ধরার নির্দিষ্ট ধাপ পরের কিস্তি-তে।
8. WebORCA মাইগ্রেশনে কী বদলায়
এখনকার ORCA «WebORCA»-তে মাইগ্রেশন পর্বে। সরবরাহের রূপ মূলত দুইটা।
- WebORCA ক্লাউড সংস্করণ — ORCA ম্যানেজমেন্ট অর্গানাইজেশনের ক্লাউড সার্ভিস হিসেবে Nichi-Rece ব্যবহার। চিকিৎসা প্রতিষ্ঠান সার্ভার ম্যানেজমেন্ট থেকে মুক্ত। আবেদন স্বীকৃত সাপোর্ট প্রোভাইডার দিয়ে যায়, অফিসিয়াল গাইডে আবেদন থেকে সার্ভিস শুরু পর্যন্ত প্রায় 3 সপ্তাহ ধরা। চিকিৎসা প্রতিষ্ঠান নিজের জায়গায় সার্ভার রাখে না, ব্রাউজার থেকে ব্যবহার করে, চিকিৎসা ফি সংশোধনের প্রোগ্রাম আপডেটও ক্লাউড পাশে একসাথে হয়। চার্জ প্রতি প্রতিষ্ঠান মাসিক।
- WebORCA অন-প্রেম সংস্করণ — প্রতিষ্ঠানের সার্ভার (Ubuntu)-এ ইনস্টল করে ব্যবহার। বর্তমান সরবরাহ Ubuntu 22.04 (jammy)-এ Nichi-Rece Ver5.2.0।
মাইগ্রেশনের সময়রেখায় ধরে রাখার কথা দুটো।
এক, মাইগ্রেশনের পথ অফিসিয়ালি দেওয়া। ORCA Project «Nichi-Rece অপারেশন এনভায়রনমেন্ট মাইগ্রেশন গাইড» প্রকাশ করেছে; Ubuntu 16.04 / 18.04 / 20.04-এ চলা পুরনো (MONTSUQI সংস্করণ) Nichi-Rece 5.1.0 / 5.2.0 থেকে WebORCA অন-প্রেম (Ubuntu 22.04 + 5.2.0)-এ যাওয়ার ধাপ লক্ষ্য হিসেবে স্পষ্ট। উল্টোদিক, অর্থাৎ নিচের OS বা নিচের Nichi-Rece ভার্সনে যাওয়া যায় না।
দুই, «সব চিকিৎসা প্রতিষ্ঠান কবে নাগাদ WebORCA-তে» এমন একরকম সময়সীমা প্রকাশিত নয়। মাঠে যে সময়সীমা কাজ করে, তা OS ও Nichi-Rece প্যাকেজ জোড়ায় সেট সাপোর্ট শেষের তারিখ; এটা «Nichi-Rece প্যাকেজ ও OS সাপোর্ট শিডিউল» হিসেবে প্রকাশিত, শেষের কাছাকাছি ভার্সন আলাদা করে জানানো হয়। ইন্টিগ্রেটিং সিস্টেম বানানো পাশের কাছে «WebORCA মাইগ্রেশন কবে» নয়, কাউন্টারপার্ট চিকিৎসা প্রতিষ্ঠান যে Ubuntu ও Nichi-Rece ভার্সন চালায়, আর সেই সাপোর্ট শেষের তারিখ দেখাই সময়রেখা ধরার মাঠের উপায়।
জরুরি কথা: দুটোই ভিতরে একই Nichi-Rece। চলা সফটওয়্যার সরবরাহের রূপে আলাদা হয়ে যায় না; API-এর ধরন ও আচরণ মূলত এক। ইন্টিগ্রেট করা ইঞ্জিনিয়ারের ধরে রাখার ফারাক ইমপ্লিমেন্টেশন নয়, কানেকশন ঘিরে জমা।
- API রিকোয়েস্ট পাথে ক্লাউড সংস্করণে
/apiপ্রিফিক্স, কানেকশন তথ্য ও অথেন্টিকেশন সেটিং সরবরাহের রূপ অনুযায়ী আলাদা — এই প্রবেশপথের ফারাক। API স্পেক নিজেই দুই রূপে এক। - ক্লাউড সংস্করণে প্রতিষ্ঠানের ভিতরের ইন্টিগ্রেটিং সিস্টেম ইন্টারনেট পেরিয়ে API ডাকে, তাই নেটওয়ার্ক পথ ও বিঘ্নে ডিগ্রেডেড অপারেশনের ডিজাইন অন-প্রেম গঠনের চেয়ে বেশি ভাবতে হয়।
- প্রতি মাসে প্রকাশিত সোর্সে WebORCA-এর ডেফিনিশনও যেমন আছে তেমনই থাকে (উদাহরণ:
record/-এর নিচে.db.weborcaফাইল)। একই সোর্স ট্রি দুই রূপ সামলায়, তার প্রমাণ; সোর্স পড়ে পাওয়া জ্ঞান ক্লাউড সংস্করণেও চলে। মনে রাখুন.weborcaসংস্করণে রেসপন্সের অ্যারে সীমা ইত্যাদি সমন্বয় করা ডেফিনিশন আছে, তাই খুঁটিনাটি দেখতে WebORCA ডেফিনিশন আছে কি নাও দেখুন।
9. সারাংশ — ইঞ্জিনিয়ারের ধরে রাখার কথা
- ORCA (Nichi-Rece) ইলেকট্রনিক মেডিক্যাল রেকর্ড নয়, রেসেকন। রোগী, ইনস্যুরেন্স, রোগনির্ণয়, চিকিৎসা কার্যক্রম, ফি পয়েন্ট — দাবি-পাশের ডেটার কোর ধরে, চিকিৎসা প্রতিষ্ঠানের আয় এখান দিয়ে দাবি হয়।
- রেসেকনের আসল কঠিন কাজ প্রতি দুই বছরের চিকিৎসা ফি সংশোধন কয়েক দশক ধরে ধরে রাখা। ORCA সোর্সের সংশোধন ইতিহাস সেই রেকর্ড।
- 2001-এর JMA IT ঘোষণা থেকে চলা ওপেন-সোর্স ব্যবসায়িক সিস্টেম, সোর্স প্রতি মাসে tarball হিসেবে প্রকাশ। লাইসেন্স GPL নয়, 日医オープンソース使用許諾契約।
- ভিতরে COBOL 1,754টা, প্রায় 4.06 মিলিয়ন লাইন + MONTSUQI + PostgreSQL 285 টেবিল (5.2 সিরিজ পরিমাপ)। স্ক্রিন ও API একই LD ডেফিনিশনে ডিসপ্যাচ হওয়া কেন্দ্রীভূত প্রসেসিং আর্কিটেকচার।
- বাহিরের ইন্টিগ্রেশনের এখনকার প্রবেশপথ Nichi-Rece API। CLAIM 2026 সালের মার্চে সাপোর্ট শেষ। WebORCA মাইগ্রেশন চলছে, কিন্তু ক্লাউড ও অন-প্রেম দুটোই ভিতরে একই Nichi-Rece; প্রকাশিত সোর্স থেকে পাওয়া জ্ঞান দুটোতেই চলে।
পরের কিস্তিতে এই প্রকাশিত সোর্স আসলে পড়ে Nichi-Rece API-এর পুরো ছবি (কোন URL কোন COBOL প্রোগ্রাম সামলায়, অফিসিয়াল তালিকায় নেই কোন এন্ডপয়েন্ট) সোর্স থেকে ধরার উপায় সব 137 এন্ডপয়েন্টের ম্যাপিং টেবিলসহ ব্যাখ্যা করব।
10. তথ্যসূত্র
- ORCA কী - ORCA Project
- প্রযুক্তি তথ্য - 日医標準レセプトソフト - ORCA Project (সোর্স কোড প্রকাশ, API স্পেক, টেবিল ডেফিনিশন)
- 日医標準レセプトソフト API - ORCA Project
- 日医標準レセプトソフト «ORCA» - জাপান মেডিক্যাল অ্যাসোসিয়েশন ORCA ম্যানেজমেন্ট অর্গানাইজেশন
- 日医標準レセプトソフト কমার্শিয়াল সংস্করণ - জাপান মেডিক্যাল অ্যাসোসিয়েশন ORCA ম্যানেজমেন্ট অর্গানাইজেশন
- WebORCA ক্লাউড সংস্করণ - ORCA Project
- 日医標準レセプトソフト [WebORCA ক্লাউড সংস্করণ] - জাপান মেডিক্যাল অ্যাসোসিয়েশন ORCA ম্যানেজমেন্ট অর্গানাইজেশন (আবেদনের পথ, সরবরাহের রূপ, চার্জ)
- Nichi-Rece অপারেশন এনভায়রনমেন্ট মাইগ্রেশন গাইড - ORCA Project (WebORCA অন-প্রেমে মাইগ্রেশনের লক্ষ্য ও ধাপ)
- 日医標準レセプトソフト ব্যবহারকারীদের জন্য - ORCA Project («Nichi-Rece প্যাকেজ ও OS সাপোর্ট শিডিউল»-এর প্রকাশস্থল)
- Nichi-Rece মূল 5.2 সিরিজ সোর্স কোড (2026 সালের জুলাই প্রকাশিত স্ন্যাপশট)
INSTALL.ja/doc/license.html/lddef/orcadb.incইত্যাদি — নিবন্ধের পরিমাপ সব এই স্ন্যাপশটে
সম্পর্কিত নিবন্ধ
কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।
FAX অর্ডার Web-এ সরাতে হলে ── দ্বৈত পরিচালনার সময়কালের নকশা ও ধাপে ধাপে মাইগ্রেশন
FAX অর্ডারকে Web অর্ডার বা CSV ইমপোর্টে সরিয়ে নেওয়ার ব্যবহারিক দিক ব্যাখ্যা করে। একবারে পুরো Web রূপান্তর কেন ব্যর্থ হয়, FAX ও Web-এর ...
EDI কী? কোম্পানিগুলোর মধ্যে অর্ডার গ্রহণ-প্রদান কীভাবে সহজ হয় ── FAX, ইমেইল ও ম্যানুয়াল এন্ট্রি থেকে ডেটা ইন্টিগ্রেশনে
EDI হলো অর্ডার ফর্ম, ইনভয়েস ইত্যাদি লেনদেনের ডেটা কোম্পানির সিস্টেমের মধ্যে বিনিময় করার ব্যবস্থা। FAX ও ইমেইলের সঙ্গে পার্থক্য, ম্যানুয...
Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ৩) — সেকেন্ডে বুট হওয়া ভার্চুয়াল মেশিন: WSL2, Windows Sandbox ও কন্টেইনার এত হালকা কেন
WSL2 ও Windows Sandbox সেকেন্ডে শুরু হয়ে এত হালকা মনে হয় কেন? এই নিবন্ধ ডায়নামিক বেস ইমেজ ও ডাইরেক্ট ম্যাপ থেকে ডায়নামিক মেমরি বরাদ্দ...
Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ২) — কার্নেলও দেখতে পায় না এমন মেমরি: VBS, HVCI ও Credential Guard কীভাবে কাজ করে
সামঞ্জস্যপূর্ণ হার্ডওয়্যারে ক্লিন ইনস্টলে VBS ডিফল্টে চালু থাকে এবং হাইপারভাইজার ও SLAT দিয়ে কার্নেলের চেয়ে শক্তিশালী আইসোলেশন তৈরি কর...
Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ১) — আপনার Windows আসলে কোথায় চলছে? হাইপারভাইজার ও পার্টিশন
Hyper-V চালু করলে হোস্ট Windows নিজেই রুট পার্টিশন হিসেবে হাইপারভাইজারের উপর চলে। এই নিবন্ধ VT-x, SLAT ও VMBus-এর ভূমিকা দিয়ে ভার্চুয়াল...
সম্পর্কিত বিষয়
এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।
Windows-এর প্রযুক্তিগত বিষয়
Windows ডেভেলপমেন্ট, বাগ তদন্ত ও বিদ্যমান সম্পদ ব্যবহারের প্রবেশদ্বার।
এই বিষয়ের সাথে সম্পর্কিত সেবা
নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।
প্রযুক্তিগত পরামর্শ ও ডিজাইন রিভিউ
ইলেকট্রনিক মেডিক্যাল রেকর্ড বা প্রতিষ্ঠানের ভিতরের সিস্টেমের সাথে রেসেকনের ইন্টিগ্রেশন পদ্ধতি ঠিক করার ধাপে পুরো গঠন ধরে ডিজাইন সিদ্ধান্ত লাগে।
Windows অ্যাপ ডেভেলপমেন্ট
ক্লিনিকের Windows টার্মিনালে চলা ব্যবসায়িক সিস্টেম থেকে ORCA সার্ভারে ইন্টিগ্রেশন Windows অ্যাপ ডেভেলপমেন্টের আওতায় পড়ে।
প্রায়শ জিজ্ঞাসিত প্রশ্ন
এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।
- ORCA কি ইলেকট্রনিক মেডিক্যাল রেকর্ড?
- না। ORCA প্রজেক্টের কেন্দ্র JMA Standard Receipt Software (日医標準レセプトソフト, Nichi-Rece) চিকিৎসা ফি দাবি (রেসেপ্ট) সামলানো রেসেকন। ক্লিনিক্যাল নোট লেখার ইলেকট্রনিক মেডিক্যাল রেকর্ড আলাদা সফটওয়্যার, অনেক চিকিৎসা প্রতিষ্ঠানে ইলেকট্রনিক মেডিক্যাল রেকর্ড ও ORCA-কে API দিয়ে যুক্ত করে চলে। «ইলেকট্রনিক মেডিক্যাল রেকর্ডের ORCA» বলাটা ইলেকট্রনিক মেডিক্যাল রেকর্ডের সাথে যুক্ত করে ব্যবহার বেশি হওয়ায় জন্মানো ডাকনাম হিসেবে ধরাই সঠিক।
- ORCA (Nichi-Rece)-এর সোর্স কোড কি যে কেউ পড়তে পারেন?
- পারেন। JMA Standard Receipt Software-এর মূল সোর্স 日医オープンソース使用許諾契約 (JMA OpenSource License)-এর অধীনে প্রকাশিত, প্রতি মাসের 1 তারিখে আগের মাসের 1 তারিখের স্ন্যাপশট tarball হিসেবে ডাউনলোড করা যায়। আগের CVS রিপোজিটরি কমার্শিয়াল সংস্করণ শুরুর সাথে প্রাইভেট হয়েছে, কিন্তু সোর্স প্রকাশ নিজে চলছে।
- ORCA কোন প্রযুক্তিতে তৈরি?
- সার্ভার Linux-এ চলে, ব্যবসায়িক লজিকের বেশিরভাগ COBOL-এ লেখা। ডেটাবেস PostgreSQL, ব্যবসায়িক প্রোগ্রামের এক্সিকিউশন প্ল্যাটফর্ম MONTSUQI (panda) নামের ওপেন-সোর্স মিডলওয়্যার, ক্লায়েন্টে Java-তে তৈরি monsiaj ইত্যাদি। 5.2 সিরিজের সোর্স গুনলে শুধু COBOL প্রায় 1,750টা প্রোগ্রাম, 4 মিলিয়নের বেশি লাইন, ডেটাবেসে 280-এর বেশি টেবিল।
- ইলেকট্রনিক মেডিক্যাল রেকর্ড ও ORCA কীভাবে ইন্টিগ্রেট হয়?
- এখনকার সুপারিশ Nichi-Rece API। ইলেকট্রনিক মেডিক্যাল রেকর্ডের মতো ইন্টিগ্রেটিং সিস্টেম HTTP-তে রিকোয়েস্ট পাঠিয়ে রোগীর তথ্য আনে, চিকিৎসা কার্যক্রম নিবন্ধন করে। Nichi-Rece পাশ থেকে ইভেন্ট জানানোর PushAPI-ও আছে। আগে থেকে চলা CLAIM (মেডিক্যাল তথ্য বিনিময় নিয়ম) দিয়ে ইন্টিগ্রেশন 2026 সালের মার্চে সাপোর্ট শেষ, তাই এখন থেকে বানানো ইন্টিগ্রেশন API ধরে ডিজাইন করাই যুক্তিসঙ্গত।