A discharge team may have two unfinished jobs at once: ensuring the right instructions are available and arranging the practical work around leaving hospital. Combining them into an editable family chat creates an authority problem. Who approved the wording, and which version should a patient follow?
Proposed hospital-software design, not a delivered discharge system. This guide describes a portal that coordinates access, logistics and questions around a clinician-controlled instruction package. It does not interpret the instructions, decide discharge readiness or generate advice.
Preserve clinical authority in the content model
The US AHRQ IDEAL discharge-planning resource emphasizes patient/family partnership, plain-language explanation and clinician use of teach-back. AHRQ's page was last reviewed in December 2017. It is a source for the human discharge process, not evidence that a proposed portal improves outcomes.
The NSW Agency for Clinical Innovation's discharge guidance describes multidisciplinary planning and shared decisions with patients and families or carers in a perioperative setting. Its Australian clinical context must not be flattened into a generic global software requirement.
Translate those process lessons into an explicit product boundary: authorized hospital staff own clinical content and its explanation. The portal displays the approved artifact and organizes agreed logistical tasks. Reading an artifact is not evidence of comprehension. Any clinical comprehension assessment belongs to qualified staff, not a score derived from opening a link.
Publish a package, not an editable copy of the instructions
An illustrative release manifest might be:
{
"case_id": "CASE-DEMO",
"package_id": "PKG-DEMO",
"version": 4,
"artifact_ref": "protected-artifact-reference",
"content_hash": "fixture-hash-not-a-real-document",
"approved_by": "CLINICIAN-DEMO",
"approved_at": "2026-11-05T10:00:00Z",
"supersedes_version": 3,
"publication_state": "approved",
"translation_review_state": "not-requested"
}
Synthetic contract fixture, not patient data, a clinical instruction or an existing integration payload. The identifier and hash are illustrative placeholders. A hash can help detect an artifact change; it cannot establish clinical correctness or prove that the right person approved it.
Keep the approved bytes immutable. A correction produces a newly approved version and updates the current-version reference through a controlled action. Do not let a family annotation or logistics edit overwrite the artifact. Attach questions to the version they concern so staff can see whether a later correction changes the context.
Translations need their own review and a link to the source version. If the source changes, an earlier translation cannot silently inherit approval. Define who reviews language, how the person is supported while review is pending and which clinician-approved fallback is available. Automatic translation output should not become authoritative discharge guidance without the hospital's review process.
Separate access, logistics and questions
Before publishing, verify the patient's identity and the authorized supporters' access through the hospital's reviewed process. Relationship, possession of a forwarded link and responsibility for a transport booking do not automatically authorize access to the instruction package.
The portal can then coordinate three different objects:
| Object | Accountable party | What does not close it |
|---|---|---|
| Instruction package | Authorized clinical content approver | A delivery receipt, family edit or completed transport task |
| Transport/paperwork task | Named operational staff member or authorized task owner | A request being received or an intended booking not yet confirmed |
| Question about instructions | The qualified, staffed team defined by the hospital | The question being classified, forwarded or opened |
A proposed sequence is: approve the artifact; verify access; publish the version; assign agreed logistics; collect questions; route them to the appropriate staffed team; record human resolution. Clinical questions must remain with qualified staff. Software can make responsibility visible without deciding the answer or determining urgency.
Keep messages outside the protected portal minimal. Whether a particular channel should contain even an appointment or package notification requires review. Do not place patient records in the existing Wrynkle product or distribute the entire instruction package into a broad family chat.
Follow a correction after release
Illustrative failure exercise. Package version 3 has been released and a supporter has downloaded it. A clinician approves version 4. The current portal must identify version 4 clearly, show approval time and authorship, and mark version 3 superseded when it is accessed through the system.
Recheck access before sending any update notification: a supporter whose authority was revoked between versions must not receive the new package. Associate pending questions with their original version and make the correction visible to the clinical team. Do not automatically close the questions because a replacement document exists.
A downloaded file or printed sheet may remain outside the portal's control. The hospital needs an approved process for communicating corrections and handling old copies. The software should report what it published, which notice attempts occurred and which questions remain; it should not claim that every recipient now understands the corrected instructions.
Keep the integration boundary narrow
An initial integration could consume only an approved artifact and its release metadata through a hospital-authorized interface. A later bidirectional EHR integration requires separate discovery, permissions, system-owner approval and testing. The presence of an API does not imply permission to copy the whole chart, and no particular hospital integration is assumed here.
Consider whether the first release should merely reference the hospital's authoritative content system or store a protected copy. References reduce duplicate content but depend on upstream availability and access. Copies support a controlled portal view but create another place requiring version, retention, access and correction management. The hospital's privacy/security and clinical owners must decide which boundary is appropriate.
Add an audit trail for release, access grants, revocation, task assignment and human resolution. Avoid putting clinical content in general telemetry. Set retention and vendor/data-flow rules before using patient information. Institutional and jurisdiction-specific review is essential; this architecture sketch does not establish compliance.
Plan for unread content, downtime and unstaffed questions
A person who cannot use the portal needs an effective alternative. Agree accessible formats, language support, a hospital-owned offline procedure and a clear way to contact the appropriate team. Do not block discharge support behind a successful app login.
For an unread package, the system may show that it has no open receipt. It cannot conclude the person did not receive a paper copy, failed to understand or is unsafe. For incomplete transport, keep the task unresolved and visible to its operational owner. Clinical staff determine the consequences and appropriate action under hospital procedures.
An after-hours question needs a clear statement of the team's staffed hours and the hospital's approved contact alternatives. For immediate danger, people should use appropriate local emergency help, not wait for an app queue. Do not use an AI classifier to make patient-safety, urgency or autonomous triage decisions.
What Wrynkle informs, and the engineering still required
Wrynkle shows a family-facing interaction alongside deliberately shared coordination. Its walkthrough describes requests and family acknowledgment; its privacy policy distinguishes private conversations and role-limited sharing. Those are interaction lessons, not a hospital permission model or a clinical content service.
A discharge portal requires new hospital-owned approval workflows, verified patient/proxy access, an approved integration boundary, translation review, version/revocation management, audit and downtime procedures. The Wrynkle owned-product study labels institutional adaptations as proposals requiring discovery.
Wrynkle's servers and providers process content; it is not end-to-end encrypted. Its terms say it is not a doctor, medical device or emergency service. AI can misunderstand, and family alerts do not guarantee a response. This proposed portal excludes diagnosis, medication changes, clinical instruction generation, autonomous triage and promised emergency response. It is not an institutional extension already shipped in Wrynkle.
Rehearse release failures before a pilot
Use placeholder instruction artifacts with no clinical advice, synthetic identities and integrations that cannot contact real systems. Agree pass/fail thresholds with hospital clinical, operational and information-governance owners.
- Correct a package after release; verify current-version visibility, immutability, provenance and the staff correction process for old copies.
- Revoke supporter access between approval and notification; test direct resource access, not only hidden navigation buttons.
- Introduce an out-of-date translation and an old document uploaded by a supporter; neither may replace the current approved artifact.
- Leave the package unread, transport incomplete and a clinical question unanswered after hours; verify truthful operational states and the defined human handoff.
- Simulate upstream downtime and staff turnover; check that a usable approved alternative and an accountable recipient exist.
Measure version mismatches, unauthorized access attempts that succeed, unresolved task age and lost question handoffs. Clinicians own any comprehension evaluation. Readmission or clinical outcome improvements require separate evidence and are not claimed here.
Explore API and integration services or discuss the hospital's discovery scope. Do not send patient documents in an initial enquiry. The related clinic follow-up guide addresses appointment callbacks rather than discharge content authority.
Sources and evidence limits
- AHRQ IDEAL discharge planning: patient/family partnership, plain language and teach-back in a US hospital process; not a portal outcome study.
- NSW ACI discharge instructions: multidisciplinary perioperative planning and patient/family involvement in an Australian context.
- Wrynkle walkthrough, privacy and terms: documented interaction and processing boundaries only.
Sources checked 5 November 2026. The manifest and workflow are original proposals. No hospital customer, clinical validation, EHR integration or compliance certification is asserted.