Apps for hospitals fall into three groups: mobile tools for clinicians, apps for patients and families, and operations software that keeps beds, staff and equipment moving. Each group serves a different user and reaches the EHR by a different path.
This guide describes what each group of hospital apps does, which EHR interface each one usually needs, the federal rules that apply to them, and the decisions a hospital or vendor should settle before the first build starts.
What kinds of apps do hospitals use?
Planning software for a hospital?
Agnotic builds hospital management systems and the clinician, patient and operations apps around them, connected to the hospital's EHR.
Hospital apps fall into three categories: clinician mobile apps used at the bedside, patient apps for scheduling, records and messaging, and operations apps for beds, transport, staffing and assets. All three depend on the hospital's EHR, but they connect to it in different ways, so the category decides the integration work.
Most hospitals already run apps from their EHR vendor. A custom app earns its place when it covers a workflow the vendor app does not, or when it joins EHR data with data from other systems.
What do clinician mobile apps need from the EHR?
Clinician apps need the current patient, the signed-in user and the right to read and sometimes write that patient's data. SMART App Launch gives them the first two through an EHR launch, and write access depends on the EHR vendor's own APIs.
- Launch context: In an EHR launch, the EHR passes a launch parameter and the app receives the patient and encounter in its token response, so the clinician never searches for the patient twice.
- Shared devices: Hospital phones and tablets move between staff at shift change. Each user signs in under their own identity, and sessions end on handover, which maps to the HIPAA safeguards for unique user identification and automatic logoff.
- Bedside tasks: Typical uses include reviewing results, documenting a short assessment, scanning a barcode and photographing a wound. Each write path must be confirmed against the EHR's own APIs before it is promised.
- Alerts: Push notifications that wake a phone should carry no PHI. The notice says something needs attention, and the detail loads after sign-in.
Epic customers, for example, can use Epic's own mobile apps: open.epic names Haiku and Canto for physicians and Rover for nurses. A custom clinician app should fill a gap those apps leave, not rebuild them.
How do patient apps reach hospital records?
Patient apps reach hospital records through the certified FHIR API with a SMART standalone launch, where the patient usually signs in with the hospital's patient portal credentials. That API is for reading data, so booking, messaging and payments need other interfaces.
Under 45 CFR 170.315(g)(10), certified health IT must offer a standardized read API for patient and population services, using US Core and SMART App Launch. The hospital's patient portal stays the main place for patients to view and download records, so a new app should link to it rather than copy it.
Who provides the app matters for HIPAA. An app the hospital offers is usually operated by a vendor that is the hospital's business associate. An app a patient picks on their own to get their records is a different case: it is the patient's tool, and the hospital does not take on its developer as a business associate.
Patient apps also face accessibility rules. The HHS Section 504 rule at 45 CFR 84.84 adopts WCAG 2.1 Level AA for the web content and mobile apps of HHS funding recipients, and an interim final rule moved compliance to 11 May 2027 for recipients with 15 or more employees.
Plan for family members too. Parents, adult children and caregivers often manage a patient's appointments and messages, so the app needs proxy access that follows the hospital's portal rules for who may see what, including any separate rules the hospital applies to adolescent records.
Which operations apps run behind the scenes?
Operations apps manage beds, patient transport, room cleaning, staff schedules, supplies and equipment. They rarely show clinical detail, but they depend on knowing where every patient is, which usually means an HL7 v2 ADT feed.
- Bed management: Tracks bed status from occupied to dirty to clean to ready. It listens for ADT A01 admit, A02 transfer and A03 discharge events to know when a bed changes state.
- Transport and cleaning: Assigns porters and cleaning staff to tasks raised by those same events, and records when each task starts and ends.
- Staff scheduling: Matches staff to units and shifts. It usually connects to the HR and time systems rather than the EHR.
- Asset tracking: Locates pumps, wheelchairs and monitors through RFID or real-time location tags, and flags equipment due for maintenance.
- Supply and inventory: Tracks stock on units and in stores, with reorder points, often linked to the hospital's ERP.
These apps hold less PHI than clinical apps, but a bed board that shows patient names on a hallway screen still exposes PHI. Decide which screens show names and which show initials or room numbers only.
ADT feeds need careful handling. A cancelled admit, transfer or discharge arrives as its own event, A11, A12 or A13. An app that ignores a cancelled discharge shows a bed as free when the patient never left. Updates to patient details arrive as A08. Test each event type, including messages that arrive out of order after an interface engine restart.
Matching each app to its EHR interface
Pick the interface by what the app needs: context, records, events or bulk data. This comparison covers the paths a hospital app usually uses.
- SMART EHR launch: Clinician apps opened from inside the chart. Gives patient and user context and FHIR read access, with vendor APIs for writes.
- SMART standalone launch: Patient apps and clinician apps opened outside the EHR. The user signs in, then picks or is matched to a patient.
- HL7 v2 interfaces through an interface engine: Operations apps that need ADT events, and apps that receive orders or results through ORM and ORU messages.
- FHIR Subscriptions or vendor events: Apps that need to react to a change without polling, where the EHR supports them.
- Bulk Data export: Analytics and population tools that need data for many patients at once, run as scheduled asynchronous jobs.
- CDS Hooks: Decision support that appears as cards at points such as opening a chart or signing an order, where the EHR supports the hook.
Many apps use two paths. A transport app might take ADT events from the interface engine and launch from the chart for one patient. Plan both from the start, with one owner for each.
Test each path against the hospital's own environment before the build is quoted as done. Vendor sandboxes carry synthetic data and default settings, while a live site has its own scopes, enabled resources, local codes and network rules, and those differences are where integrations slip.
Which rules apply to hospital apps?
HIPAA applies to every app that handles PHI for the hospital, and the other rules depend on who uses the app and what it does. Treat each one as a design question, not a late review.
- Security safeguards: Each user has their own sign-in, sessions end on shared devices, access is logged, and data is encrypted on the device and in transit.
- EHR write limits: The certified API reads data. Writing needs the EHR vendor's own APIs or an HL7 v2 interface, so confirm each write early.
- Accessibility: Patient screens meet WCAG 2.1 Level AA, with the Section 504 deadlines above as the outer limit for hospitals that receive HHS funding.
- Device status: An app that only schedules, messages or shows records is usually not a medical device. One that analyzes data to diagnose or treat may be, so get a regulatory view before building that feature.
- App store review: App stores may review medical apps more closely, so prepare evidence for any health claim the listing makes.
Bring the hospital's privacy, security and compliance staff into design reviews for each of these. Their answers change screens and data flows, which is cheap to do before the build and expensive after go-live.
Write the answers into the app's design record. When the EHR is upgraded or a new unit adopts the app, the next team can see why each choice was made instead of reopening it.
What to settle before the first hospital app build
Settle the decisions below in writing with the hospital's IT, security and clinical teams. Each one is cheap to agree in week one and slow to change after go-live.
- 1. Category and user: Name the app's group and its users. A clinician app and a patient app with the same features are still two security models.
- 2. Vendor overlap: List what the EHR vendor's own apps already do, and build only the gap.
- 3. Interfaces: Choose the paths from the comparison above and confirm each one in the hospital's environment, not only in a vendor sandbox.
- 4. Write-back: Confirm every write the app needs with the EHR team, including which API or HL7 v2 message carries it.
- 5. Devices: Decide between hospital-owned shared devices and staff phones, and how sign-in, wipe and loss reporting work for each.
- 6. Accessibility: Set WCAG 2.1 Level AA as the floor for patient-facing screens, with testing on real assistive technology.
- 7. Support: Agree who answers when the app fails at 3 a.m., and how an EHR upgrade is tested against the app before it goes live.
How Agnotic can help
A hospital app is only as useful as its connection to the EHR and to the people who run the wards. Agnotic Technologies builds hospital management systems and the apps around them for the client: clinician tools launched from the chart, patient apps on the certified API, and operations apps driven by ADT events.
Agnotic starts with the category, interface and write-back decisions above, confirms each interface in the hospital's environment, and builds to WCAG 2.1 Level AA for patient-facing screens.
Plan your hospital app with Agnotic
Explore hospital management system development, or browse more guides for healthcare software teams.
Related reading on Agnotic
Continue with EHR mobile app development, Epic Rover, Epic SMART on FHIR integration, HL7 ADT messages and MVPs for hospitals and clinics.
