TL;DR: A patient portal fails at launch for boring reasons: identity checks that lock out real patients, consent screens nobody designed, records that cannot be shared with the national exchange, and hosting that quietly breaks a data-residency rule. This guide walks through what to settle before go-live for hospitals in India and the UAE, and previews the 5-area readiness checklist in the free PDF.
Why portal launches go wrong
Most hospital portals are scoped as a front-end project: a login, an appointments page, a place to download reports. The trouble starts underneath. The portal has to read from the hospital information system (HIS), the lab and imaging systems and billing, and it has to do so under rules about consent, residency and exchange that differ by country, and in the UAE by emirate.
If you are comparing vendors or planning an in-house build, the useful question is not "what features does the portal have?" but "what must be true on the day we let the first patient in?" That is what a launch-readiness checklist captures. The sections below cover the five areas we recommend settling first. The downloadable PDF turns them into a scored checklist your team can work through.
1. Scope and ownership
Before any screen is designed, write down who owns the portal after launch. Portals tend to sit between IT, medical records, patient experience and compliance, and without a named owner the post-launch backlog stalls.
Decide the first release scope explicitly. A common sensible first release covers registration and identity, appointment booking and rescheduling, viewing visit summaries and lab reports, bill viewing and payment, and secure messaging for non-urgent questions. Prescriptions refills, teleconsultation and family accounts are better treated as phase two unless your HIS already supports them cleanly.
Also list every upstream system the portal will read from and the integration method for each (HL7 v2 feed, FHIR API, database view, vendor API). Gaps here are the most common cause of slipped launch dates.
2. Identity, consent and privacy
India. The Digital Personal Data Protection (DPDP) Rules were notified in November 2025 with a phased commencement. According to law-firm summaries, the Data Protection Board provisions took effect immediately, consent manager provisions follow after one year (November 2026), and the core obligations (notice, consent, children's data, security safeguards, breach handling and retention) apply after eighteen months, in May 2027 (AZB & Partners). A portal launched now should be designed to meet those obligations from day one rather than retrofitted. Practical implications:
- A plain-language privacy notice at registration that says what is collected, why, and who to contact.
- Consent captured per purpose, with an audit trail, and a working way to withdraw it.
- A route for verifiable parental or guardian consent for children's accounts. Summaries describe healthcare-related exemptions, so have counsel confirm how they apply to your portal.
- Breach-handling procedures that include informing affected patients.
UAE. Federal Law No. 2 of 2019 on the use of ICT in health fields governs health data. As summarised by Al Tamimi, it restricts storing, processing or transferring health data outside the UAE unless approved by a health authority or the Ministry, and sets a minimum retention period of 25 years from the last procedure (Al Tamimi). That analysis dates from 2019, and exemptions and implementing rules have developed since, so confirm the current position with your legal adviser and the relevant authority (DHA in Dubai, DoH in Abu Dhabi, MoHAP for the northern emirates).
Identity. Decide how patients prove who they are: mobile OTP, national ID, or the ABHA address in India. Test the unhappy paths: a patient with a changed mobile number, a parent managing a child's record, an elderly patient helped by a relative. Locked-out patients become front-desk queues.
3. Interoperability and national exchanges
A portal that only shows data from one hospital's database is a missed opportunity, and in some markets a compliance gap.
India: ABDM. The Ayushman Bharat Digital Mission structures participation in milestones. Developer documentation describes M1 as ABHA creation and verification at registration, M2 as acting as a Health Information Provider (linking records to a patient's ABHA address and sharing them with consent, structured in FHIR), and M3 as acting as a Health Information User. Hospital management software is listed as needing M1, M2 and M3, plus facility registration. Patient-facing apps can also support Scan and Share, where a patient scans a facility QR code to share their profile at registration. Check the official ABDM sandbox documentation for current requirements before you commit to a plan, since community mirrors may lag.
UAE: HIE platforms. Abu Dhabi's Malaffi, Dubai's NABIDH and the federal Riayati platform (the National Unified Medical Record run by MoHAP) are the health information exchanges. The Department of Health announced in January 2023 that the three had been electronically linked under an agreement between the authorities (DoH Abu Dhabi). Ask your HIS vendor which exchange feeds you already publish, because the portal should show a patient the same record the exchange holds, not a divergent copy.
In both markets, FHIR and HL7 support in the underlying HIS is what makes this tractable. Ask for the actual interface specification, not a feature tick.
4. Hosting, security and resilience
Residency is a launch gate, not a footnote. Decide where the portal, its database, its backups and its logs live, and write it down. For UAE providers that usually means in-country hosting unless an approved exemption applies. For Indian providers, align hosting with your DPDP obligations and any contractual commitments.
Then cover the basics that audits look for: role-based access in the back office, encryption in transit and at rest, session timeouts, rate limiting on login and OTP endpoints, an access log of who viewed which record, tested backups and a documented recovery plan. Run an independent penetration test before go-live and track findings to closure.
5. Accessibility, language and support
Aim for WCAG 2.2 level AA, which became a W3C Recommendation on 12 December 2024 (W3C). Patients include older adults and people using screen readers, and reports are often read on a phone.
Plan languages deliberately. In India that may mean English plus one or more regional languages; in the Gulf, many providers expect Arabic and English. Right-to-left layout is real engineering work, so confirm what your vendor has actually built rather than assuming.
Finally, plan support: who answers the "I can't log in" call, what the escalation path is, what hours, and how patient feedback reaches the product owner.
Common mistakes we see in portal programmes
Treating consent as a checkbox. A single "I agree" at sign-up rarely holds up once you need to explain what was agreed to, by whom and when. Design consent as a record with a purpose, a version of the notice and a timestamp, then test withdrawal as carefully as you test granting.
Launching reports before they are clinically ready. Releasing results to patients the moment they are filed can surprise patients and clinicians alike. Agree release rules with your clinical leads: which result types are immediate, which wait for clinician review, and how sensitive results are handled.
Ignoring the unhappy path in identity. Shared family phones, changed numbers and assisted access by relatives are normal. If the portal cannot handle them, the front desk will, and adoption stalls.
Assuming the vendor's hosting answer is the compliance answer. Ask where backups and logs live, which sub-processors touch the data, and what happens during support access from another country.
Skipping a pilot. A small pilot with real patients and staff, one department at a time, finds the issues no test script will. Set exit criteria in advance (for example, no open critical defects and a working support rota) so the pilot ends with a decision rather than a drift.
A launch-day scorecard
Score each area red, amber or green before approving go-live:
| Area | Green means |
|---|---|
| Scope and ownership | Named owner, frozen release 1 scope, upstream systems mapped |
| Identity, consent, privacy | Notice and consent flows tested, recovery paths tested, legal sign-off |
| Interoperability | Interface specs agreed, exchange or ABDM plan documented |
| Hosting and security | Residency decision recorded, pen test findings closed, backup restore tested |
| Accessibility and support | WCAG 2.2 AA audit done, languages confirmed, support rota staffed |
Any red in identity, consent or hosting should block launch. Amber items need a dated owner.
Where Syslabs fits
Syslabs builds healthcare software and advises on technology selection. If you are still choosing between vendors, our technology vendor evaluation work helps structure that decision, and our compliance and risk consulting team can help map the rules above to your setup. Our Hospital Information System, due to launch on 20 December 2026 with India first, is designed around FHIR/HL7 interfaces, multi-currency and VAT handling, and in-country hosting; see the HIS overview for current details. Pricing is scoped on a consultation.
Next step
Download the checklist below and score your current state. If you would like a second pair of eyes on the result, book a consultation.
