Epic In Basket

What is Epic In Basket?

Epic In Basket is the electronic messaging system used within Epic applications, where clinicians, staff and shared pools receive messages and tasks tied to patients. Health systems configure which message types exist, who receives them and how they are grouped, so the same event can land with a physician at one organization and a nurse pool at another.

What arrives in a clinician's In Basket?

Anything that needs a person to read, sign, answer or act can arrive there. Epic's EHI export documentation for the In Basket message table shows how varied the sources are.

• Transcriptions from outside: The table links messages to dictation transcriptions created outside Epic and sent to In Basket through an interface.
• Third-party questionnaires: It stores the note for a message created when a patient submits a third-party questionnaire.
• Patient-entered flowsheet data: It records a message type for patient-entered flowsheet messages, either Alert or Notification, which is how readings a patient files can reach the care team.
• Department workflows: It carries fields for messages from Anesthesia, for chart deficiency categories and for appointment notifications.

Patient portal messages are answered from In Basket too, as the NYU Langone study below shows, and health systems route other review items there according to their own configuration. The result is one queue where a vendor's notice competes with every other item for a clinician's attention.

How can an outside system put a message there?

An outside system reaches In Basket indirectly: it sends a communication, document or data point through an Epic interface, and the customer's configuration decides whether that creates an In Basket item and for whom. There is no general-purpose call to drop a free-form message into a named clinician's inbox.

• Provider communications: open.epic's Incoming Provider Communications Interface takes letters written in other systems and routes them to the recipient, a provider or department, by their preference for In Basket, fax or mail.
• Transcriptions: The Incoming Transcriptions interface was built to match dictations with their transcriptions, and the IB_MESSAGES table shows such outside transcriptions arriving in In Basket through an interface.
• Scanned and outside documents: The Incoming Scanned Document Link takes HL7 MDM messages that link outside documents to the chart.
• Notes by FHIR: Epic on FHIR lists DocumentReference create for clinical notes in R4, for apps that file a note the customer then routes.
• Patient-entered data by FHIR: Observation create for vital signs and flowsheets, and QuestionnaireResponse create for patient-entered questionnaires, can feed the alerts and notifications the customer builds on those entries.

Epic on FHIR's Communication resources are scoped to community resource referrals, patient education and customer relationship management. They are not a general channel for clinician messages, so plan the design around the paths above.

Recipients are the hard part. Your system knows a clinician by its own user ID or an NPI, while Epic routes by its own provider, department and pool records, so the interface needs an agreed identifier and a rule for any message whose recipient cannot be matched.

Message, result, note or alert?

Pick the path by what the clinician must do with the information. The wrong choice puts a review task where a reference document belongs, or hides an urgent finding in a document list.

• Needs a signature: File it as a transcription or note, so it lands as a review and sign task for the author or the responsible clinician.
• Needs to be on the chart for reference: Link it as a document, with no inbox item unless the customer asks for one.
• Needs a clinical decision now: Send it as a result or a patient-entered reading that the customer flags as an alert, and agree the threshold with the clinical owner first.
• Needs a reply to an outside clinician: Use provider communications, which respects each recipient's preference for In Basket, fax or mail.
• Needs action while the clinician is in the chart: Consider CDS Hooks instead, which shows a card in the ordering or chart workflow rather than adding an inbox item.

Write the decision down for each event your product produces, with the recipient type, the expected action and the customer owner who approved it. That table becomes the interface specification the analysts build from.

What does research say about AI-drafted replies?

Early evidence suggests drafts can save effort without lowering content quality, though they do not remove review. A 2024 study in JAMA Network Open tested EHR-integrated generative AI drafts for patients' In Basket messages at NYU Langone Health.

• Design: 16 primary care physicians rated 344 message responses, 175 drafted by generative AI and 169 written by health care professionals, without knowing which was which.
• Content: Information content quality was similar for AI and human responses.
• Style: AI drafts were rated higher for communication style, and usable AI drafts were more often rated empathetic.
• Readability: AI drafts were harder to read, at a Flesch-Kincaid grade of 8.1 against 6.5 for human responses.

For a vendor building any message drafting feature, the lesson is in the readability gap. Test drafts against a reading level target, keep the clinician as the sender who reviews and signs, and log which text came from the model.

Why message volume is a design constraint

Every new In Basket item takes clinician time, so a product that adds messages has to earn each one. Expect the customer's Epic team to question any design that would flood a shared pool.

• Unfiltered device readings: Every reading from a home device becomes a message, and clinicians stop opening them. Triage readings before anything reaches the inbox.
• Wrong recipient: Messages go to the attending physician when a nurse pool or care manager owns the follow-up.
• Duplicate notices: The same event arrives as a document, a result and a provider communication.
• No closure: The vendor's system never learns that the message was handled, so it sends reminders.
• Free text only: Structured values arrive as prose, and the clinician cannot trend or act on them.
• No volume estimate: The analysts are not told how many messages a day the go-live will add, so they cannot size the pools.

Give the customer a switch. A setting that turns one message type off, or sends it to a pool instead of a person, lets the clinical owner fix a volume problem in a day instead of waiting for your next release.

Testing delivery before go-live

Test every event type end to end in the customer's test environment, with recipients that mirror production. A message that reaches the wrong folder in testing reaches the wrong clinician after go-live.

• 1. Build the event table: Every event your product sends, with recipient type, path and expected action.
• 2. Mirror recipients: Test providers, departments and pools that match how production is set up.
• 3. Send each event type: Confirm it lands as the intended item, in the intended place, for the intended recipient.
• 4. Test the edges: Unknown recipient, patient not found, duplicate send, and a recipient who has left or changed role.
• 5. Check the chart: The document or reading sits on the right patient and encounter, and the audit trail names the interface as the source.
• 6. Measure volume: Run a realistic day of events and give the count to the analysts and the clinical owner.
• 7. Agree monitoring: Name who watches for rejected messages after go-live and how failed ones are resent.

Which privacy and security rules shape message content?

The HIPAA Privacy and Security Rules both apply. Messages that carry PHI between your system and Epic need the same safeguards as any other ePHI.

• Minimum necessary: The Privacy Rule standard at 45 CFR 164.502(b) and 164.514(d) applies to many uses and disclosures, so a notice should carry what the recipient needs, not the whole record.
• Business associates: Under 45 CFR 164.502(e), a vendor that sends or receives PHI for a covered entity needs a business associate agreement in place first.
• Audit and identity: 45 CFR 164.312 makes audit controls and person or entity authentication required safeguards for the systems on both ends.
• Transmission security: Encryption in transmission is an addressable specification under 164.312(e), which means implement it or document why an equivalent measure is reasonable.

Keep diagnoses and values out of notice text where a short notice will do. A message that says a new document is ready, with the detail kept in the chart, exposes less when it is forwarded or shown on a shared screen.

How Agnotic can help

A product that talks to clinicians needs a routing plan before it needs code. Agnotic Technologies builds the plan and the plumbing: an event table that maps each signal to a recipient and path, HL7 v2 provider communication and document feeds, FHIR writes for notes, readings and questionnaires, and triage logic that keeps raw device data out of the inbox.

Agnotic works with the customer's Epic analysts on message types and pools, estimates daily volume before go-live, and builds to HIPAA Security Rule safeguards on both sides of the interface.

Sources

• University of Iowa Health Care: Epic nursing resources, including In Basket
• open.epic: EHI export specification, IB_MESSAGES table
• open.epic: HL7 v2 clinical interfaces, including Incoming Provider Communications
• open.epic: FHIR interfaces, including DocumentReference, Observation and Communication
• JAMA Network Open (2024): Large Language Model-Based Responses to Patients' In-Basket Messages
• 45 CFR 164.502: Uses and disclosures, minimum necessary and business associates
• 45 CFR 164.312: Technical safeguards