E-Signatures: Technical Reference

This page describes how CareLaunch captures, stores, protects, and audits electronic signatures collected through the Signature question type in forms. It is written for security, privacy, and compliance reviewers who need to evaluate the feature, and can be shared with those teams directly.

For how to add a Signature field to a form, see Forms & Questionnaires.

Summary

Topic	Behavior
Capture method	Hand-drawn signature on screen (mouse, finger, or stylus) inside an authenticated session
Storage	Stored as a PNG image embedded in the patient's FHIR QuestionnaireResponse, in the customer's isolated FHIR data store
Authorization	The server verifies that the signed-in user is permitted to act for the patient before the response is saved or updated
Audit trail	A dedicated Signature Captured audit event records who signed, from which IP address and browser, for which patient, on which response, and when — in addition to the request-level audit log kept for every write
Integrity	The FHIR store keeps every version of the response; a signed version is never overwritten or deleted by a later edit
Encryption	AES-256 at rest, TLS in transit (see Security Overview)
Retention	Retained with the patient record until the customer requests deletion; audit records retained for 7 years

How a Signature Is Captured

1. A form builder adds a Signature field to a form and may mark it required.
2. The patient (or a staff member completing a form on the patient's behalf) opens the form while signed in to CareLaunch.
3. The signer draws their signature in the signature box. Undo removes the last stroke; Clear empties the box. The signer must actively draw — there is no pre-filled or typed signature.
4. If the field is required, the form cannot be submitted until a signature is present. Validation runs again at the moment of submission, so a signature that was cleared after the page was first validated (for example after browser Back navigation) still blocks the save.
5. On submit, the signature is converted to a PNG image and sent to the CareLaunch API with the rest of the form response.

When a previously submitted response is opened in review mode, the signature box is locked and displays the stored image; it cannot be redrawn from the review view.

How a Signature Is Stored

CareLaunch is FHIR R4-based. A completed form is a QuestionnaireResponse resource, and the signature is one answer inside it.

Element	Value
Resource	QuestionnaireResponse — one per patient per form submission
subject	Reference to the Patient the response belongs to
questionnaire	Reference to the Questionnaire (form definition) that was signed
status	completed once submitted
Signature answer	valueAttachment on the Signature question's item
valueAttachment.contentType	image/png
valueAttachment.data	The signature image, base64-encoded, embedded directly in the resource
valueAttachment.title	Signature — identifies the attachment as a captured signature
valueAttachment.creation	Server-assigned UTC timestamp of when the signature was received and saved. The API overwrites any client-supplied value for a new or changed signature, so this time never depends on the signer's device clock
meta.versionId / meta.lastUpdated	Assigned by the server for every saved version

Key properties of this design:

• The signature lives inside the clinical record. It is not stored as a separate file, on a CDN, or with a third-party e-signature vendor. It is part of the same FHIR resource as the answers it attests to, so the signature and the signed content cannot be separated.
• Tenant isolation. Each customer organization has its own FHIR data store. Form responses, signatures, and their audit events never share a store with another customer.
• Server-side timestamps are authoritative. valueAttachment.creation is stamped by the CareLaunch API at save time, in UTC; a value sent by the browser is discarded for any newly captured signature. It is corroborated by the server-assigned meta.lastUpdated on the response version and the recorded time on the Signature Captured audit event.

Who Can Sign

Signing requires an authenticated CareLaunch session. There is no anonymous signing link.

Before a signed response is created or updated, the API verifies that the caller is allowed to act for the patient named in the response:

• Patients can only submit responses for themselves (and for dependents linked to their account, where proxy access is configured). A patient session cannot create or modify a response for an unrelated patient, even if it supplies that patient's identifier.
• Staff (administrators and practitioners) can submit and update responses for patients within their organization, subject to their role.
• On update, the API additionally confirms the caller is authorized for the existing response being modified, and rejects requests where the response identifier in the body does not match the one in the URL.

If any of these checks fail, the request is rejected and nothing is written — neither the response nor an audit event.

Audit Trail

Two independent audit records are produced for every signed submission.

1. Signature Captured event

Whenever a response containing a signature is created, or an update introduces a new or changed signature, CareLaunch writes a FHIR AuditEvent with the following content:

Field	Content
subtype	signature-capture / "Signature Captured"
action	C (create) for a new submission, U (update) when an existing response receives a new or changed signature
recorded	Server timestamp (UTC)
agent.who	The signed-in user's identifier and display name; linked to their Practitioner record when the signer is a staff member
agent organization	The customer organization the user was acting within
agent.network	The signer's IP address (address, typed as an IP address) and browser user agent string (carried as an extension on the network element). The IP is the true client address as forwarded by the load balancer, not the proxy's
entity (response)	Reference to the QuestionnaireResponse that was signed
entity (patient)	Reference to the Patient the response belongs to
source	The customer organization / CareLaunch application server
outcome	Success

Updates that leave an existing signature untouched (for example, a staff member correcting an unrelated answer) do not generate an additional Signature Captured event. This keeps the e-signature trail limited to genuine signing events rather than every edit of the response.

Signature Captured events are stored in the same tenant-isolated FHIR store as the patient record. Staff with access to the patient can view them in the patient chart's audit history alongside other access events.

2. Request-level audit log

Independently of the Signature Captured event, every create and update request to the API is recorded by CareLaunch's audit logging layer with the acting user, the patient the request concerned, the request path, the outcome status, a correlation ID, and a server timestamp. This log is described under Monitoring, Logging, and Alerting in the Security Overview and is retained for 7 years.

Durability of audit records

Audit recording is designed so that a signing event is never silently lost:

• The form response is saved first; the Signature Captured event is written immediately afterward.
• If the audit event cannot be written to the FHIR store (for example, during a data store outage), the record is captured through a durable failover path — a message queue, then object storage, then an alerting log entry — so it can be replayed and reconciled. The patient's submission is not rolled back, which prevents duplicate submissions from client retries.

Integrity and Version History

• The FHIR data store preserves every version of a QuestionnaireResponse. Saving a change creates a new version; the previously signed version remains retrievable with its own version identifier and timestamp.
• A later edit therefore never destroys evidence of what was signed. The signed content, the signature image, and the server timestamp of that version are all preserved together.
• If a signature is redrawn on an existing response, a new Signature Captured audit event is written, and both the old and new signature images remain in the version history.
• Stored signatures are rendered for staff strictly as raster images (image/png, image/jpeg, image/gif, image/webp). Attachment types that could carry executable content are never rendered inline.

Encryption and Infrastructure

Signatures inherit the platform's standard protections — they are not treated differently from any other PHI:

• At rest: AES-256 encryption in the HIPAA-compliant cloud FHIR data store, with per-tenant isolation.
• In transit: TLS between the signer's browser and CareLaunch, and between CareLaunch and the data store.
• Access: Role-based access control, session expiry, and optional MFA apply to anyone viewing signed responses.

See the Security Overview and HIPAA Compliance pages for the full control set and cloud provider certifications.

Retention and Deletion

• Signed responses are retained as part of the patient record until the customer designates them for deletion.
• Audit records (both the Signature Captured events and the request-level audit log) are retained for 7 years and are excluded from customer-initiated data deletion, consistent with the platform's data retention policy.

Mapping to Electronic Signature Requirements

Frameworks such as the U.S. ESIGN Act and UETA generally look for a signature to demonstrate intent, be attributable to a person, be associated with the record it signs, and be retained in a reproducible form. The table below shows how the feature supports each element so your compliance team can assess fit for your use case.

Element	How CareLaunch supports it
Intent to sign	The signer must actively draw a signature and then submit the form; a required Signature field blocks submission until signed
Attribution	Signing happens inside an authenticated session; the audit event records the user identity, IP address, and browser, and the server verifies the user is authorized for the patient
Association with the record	The signature is embedded in the same QuestionnaireResponse as the answers it attests to and cannot be detached from them
Record retention and reproduction	Full version history, server timestamps, and viewable signature images in the patient chart
Audit	Dedicated Signature Captured event plus request-level audit log, both retained for 7 years

note

CareLaunch provides the technical controls described on this page. Whether a given form, disclosure, or workflow satisfies a specific legal or regulatory requirement in your jurisdiction is a determination for your compliance and legal teams.

Recommended form design for consent and agreements

The platform does not insert disclosure text automatically. Using standard form fields, you can build a complete consent flow:

1. Add a Paragraph field containing the agreement text and any required electronic-records disclosure.
2. Add a required Checkbox or Yes/No field for explicit acknowledgment.
3. Add the required Signature field last.

All three answers are stored together in the same response and covered by the same version history and audit trail.

Current Limitations

To support an accurate risk assessment, the following are not part of the current implementation:

• Drawn signatures only. Typed-name and uploaded-image signatures are not supported through the Signature field.
• No cryptographic seal. Integrity relies on the data store's version history and access controls rather than on a hash or digital certificate bound to the signed content. There is no downloadable "certificate of completion".
• Identity assurance is account-based. The signer's identity is established by their CareLaunch login (optionally with MFA). The feature does not perform separate identity proofing (for example, knowledge-based authentication or ID document verification) at signing time.
• No third-party e-signature provider. Signatures are captured natively; the feature does not route documents through DocuSign or similar services.

Frequently Asked Security Questionnaire Items

Question	Answer
Where is the signature image stored?	Inside the FHIR QuestionnaireResponse in the customer's isolated, HIPAA-compliant FHIR data store. No separate file store or vendor.
Is the signature encrypted?	Yes — AES-256 at rest, TLS in transit, the same as all PHI on the platform.
Can a signed form be altered after signing?	A response can be edited by authorized users, but every prior version (including the signed one) is retained with server timestamps. Redrawing a signature generates a new audit event.
Who is recorded as the signer?	The authenticated CareLaunch user who submitted the response, identified by user ID and display name (and practitioner record for staff).
Can someone sign for a patient they don't have access to?	No. The server validates authorization for the named patient before saving; unauthorized requests are rejected without writing anything.
How long are audit records kept?	7 years.
Is the signer's IP address captured?	Yes. The Signature Captured event records the signer's IP address and browser user agent on the signing user's agent entry (agent.network).
Can another customer's staff see our signatures?	No. Each customer organization has a separate FHIR data store.

Related Documentation

• Forms & Questionnaires — building forms and adding Signature fields
• Security Overview — platform-wide encryption, access control, logging, and retention
• HIPAA Compliance — PHI handling and BAA coverage
• Patient Registration — using signed forms in registration workflows

---

Last updated: August 2026