Connect RAKT to the rest of your hospital
Blood centres inside hospitals rarely run alone. RAKT exposes an API so requests, results and billing can move between systems instead of being re-keyed at the boundary.
Versioned REST
Not anonymous
Schema in non-prod
Analysers + ABDM
What can be connected
Integration scope is agreed during implementation — talk to us about your stack.
Hospital information systems
Component requests raised in the HIS reach the blood bank without a second entry.
Laboratory instruments
Analyser results captured against the sample rather than transcribed from a printout.
Billing and accounting
Charges and receipts reconciled against the units actually issued.
Messaging providers
SMS and WhatsApp delivery for donor communication through your own provider.
Authenticated access
Keyed, scoped API access with the same audit trail as the rest of the system.
Data export
Scheduled extracts for your own warehouse or reporting stack.
What you actually integrate against
Issue an organisation API key
OrganisationAPIKey scopes every call. There is no public anonymous blood-bank API.
Call the module you need
Donors, bags, camps, TTI, stores, staff, accounting, settings, ABDM — under /api/v1/ with OpenAPI docs where enabled.
Instruments push; HIS pulls
Analyser webhooks post into TTI/serology. Outbound REST is for your hospital systems — we do not invent branded HIS connectors that are not in the repo.
Same auth story as the product
eRaktKosh and ABDM use their own credential surfaces. Messaging (WhatsApp / SMS) is the same stack reports and camps already use.
Org API keys, analyser webhooks, no invented HIS brands
Integration scope is real REST under /api/v1/ plus inbound instrument webhooks. Branded hospital-system connectors are agreed in implementation — we do not list adapters that are not in the codebase.
- OrganisationAPIKey on every call — no anonymous public blood-bank API
- Modules under /api/v1/: donors, bags, camps, TTI, stores, staff, accounting, settings, ABDM
- Tulip / Matrix-style analysers push results; HIS integrations pull or push against the same API
- OpenAPI / Swagger available in non-production environments for your integrators
Every re-keyed identifier is a transcription risk
A blood centre inside a hospital sits at a boundary, and the boundary is where records get retyped. A ward raises a requisition in the hospital information system, it is printed or telephoned, and somebody at your counter enters the patient identifier, the component and the quantity again. That re-keying is the same error class as a transcribed test result, with a worse failure mode: a mistyped patient identifier means a correctly crossmatched unit allotted against the wrong record. The crossmatch is testing compatibility between a unit and a sample, so it does not catch a clerical mismatch between a sample and a patient.
An API removes the boundary rather than staffing it. Requisitions arrive with their identifiers intact and issue status goes back the same way, so the ward can see where a request is without telephoning the blood bank, which quietly removes a large share of the calls that interrupt a technician mid-task. The same reasoning covers analyser results captured against a sample instead of a printout, charges and receipts reconciled against units actually issued rather than against a separate billing entry, and messaging to donors going out through your own provider so the delivery record sits with the donor.
Two honest constraints. Integration scope is agreed during implementation, because “we support HIS integration” is not a statement about your HIS: the work depends on what the other system exposes, and a hospital package that offers no outbound interface cannot be integrated with by anybody at any price. And API access is keyed, scoped and audited exactly like a user, because an integration that writes to your records with no attribution reopens the accountability hole that named accounts exist to close. Name your systems at the demo and ask for a scoped answer with a timeline rather than a yes.
Questions about api & integrations
Can RAKT integrate with our hospital information system?
Usually, and the answer depends on what your HIS exposes rather than on RAKT. Component requests raised in the HIS can reach the blood bank without a second entry, and issue status can go back the same way. Name your specific system at the demo and ask for a scoped answer with a timeline: a hospital package that offers no outbound interface cannot be integrated with by any vendor, and it is much better to establish that before contract.
Is the API documented and authenticated?
Access is keyed and scoped, with the same audit trail as the rest of the system, so every call is attributable exactly as a user’s actions are. That is deliberate: an integration that writes to your records without attribution reopens the accountability gap that named accounts exist to close. Documentation and scope are provided during implementation for the endpoints your integration needs.
Can we pull data into our own reporting stack?
Yes, over the API, which is the right pattern when a trust wants blood bank figures alongside other clinical data rather than in a separate report. Being precise about where the scheduling lives, since it is often glossed over: the API is there to be called and your side decides how often. We do not run a job on your behalf that pushes extracts to you on a timetable. This is separate from and additional to your right to a complete export of your records, which is free and on request regardless of whether you use the API.
What else can be connected?
Laboratory instruments, so results are captured against the sample rather than transcribed from a printout; billing and accounting, so charges and receipts reconcile against units actually issued; and SMS or WhatsApp messaging through your own provider, so donor communication and its delivery record stay with the donor. Each is scoped during implementation against what the other system supports.
More of what RAKT does
See this running on your own floor
Tell us how your centre works today and we will show you the parts that would change.