Teledermatology platform development

Store-and-forward patient intake workflow built around the clinical requirements of dermatological assessment. Patients submit images and clinical context without scheduling a live visit, the submission flow guides them through photograph quality requirements specific to dermatology: ambient lighting, distance, multiple angles for raised lesions, and a reference object for scale when relevant. Image quality validation runs client-side before submission using on-device checks for blur, exposure, and minimum resolution, preventing low-quality submissions from reaching the provider review queue.

Images are stored as FHIR Binary resources linked to the relevant FHIR Condition and DiagnosticReport, so the clinical context travels with the media file through the entire case lifecycle. Multiple image submissions per case handle different body sites or angles. Each submission is encrypted at rest using AES-256 and transmitted using TLS 1.3; the HIPAA Binary resource model means the image file and its associated clinical metadata are governed by the same access control and audit logging as other PHI.

Submission status updates notify patients via email and push notification when the case has been received, when it's under review, and when the provider has responded, removing the "did it go through?" uncertainty that drives support contact volume. Providers can request additional images directly from the review interface, generating a structured re-submission request that guides the patient through the specific additional photographs needed.

Conditional intake forms that collect the clinical history a dermatologist needs before opening the case, reducing back-and-forth and making the provider's review more efficient. The intake branches based on the presenting concern: a lesion submission asks about onset date, growth rate, colour change, any bleeding or crusting, prior biopsy history, personal or family history of skin cancer, and current topical treatments. A rash submission follows a different branch, distribution pattern, duration, associated symptoms, recent medication changes, prior similar episodes, and known allergen exposures.

Intake responses are captured in structured format, not free text, so the provider sees a pre-organised clinical summary rather than a block of narrative. PHI collected during intake is stored against the patient record using appropriate FHIR resources: Observation resources for structured findings, AllergyIntolerance resources for documented allergies, MedicationStatement resources for current treatments. The structured format also enables downstream analytics, the practice can report on the distribution of presenting concerns, average response time per complaint type, and the proportion of cases referred for in-person follow-up.

Sun exposure history, skin phototype (Fitzpatrick scale), and immunosuppression status are collected for every case where they're clinically relevant. Medication intake includes both prescription and over-the-counter topicals with duration fields, because treatment history is one of the first things a dermatologist needs to interpret a lesion presentation.

Case queue interface designed for dermatologist review workflow, not a generic task management dashboard. Cases display with the submitted images, structured intake summary, and patient history in a single view so the provider doesn't navigate between screens during review. Image viewing uses a zoomable viewer with annotation tools: providers can mark specific regions of interest, add callout annotations visible to the reviewing clinician, and flag areas for patient attention in the response.

Priority ordering surfaces urgent cases first: lesions flagged as rapidly changing, cases from patients with prior melanoma history, and any submission with patient-reported bleeding or ulceration. Non-urgent cases queue in submission order. The provider can filter the queue by case type, submission date, patient age group, and review status.

Response generation is structured: the provider selects a clinical disposition (no action required, prescription generated, in-person referral recommended, additional images requested, urgent referral), adds a narrative response that's visible to the patient, and attaches a care plan document where relevant. The structured disposition data feeds into practice analytics and compliance reporting. Response drafts are auto-saved so no work is lost if the provider is interrupted mid-review.

Case routing mechanism for complex presentations that warrant a second opinion or specialist review, built into the provider workflow, not relying on out-of-band communication. When a reviewing provider encounters a case requiring specialist input, they initiate an escalation from within the review interface: select the specialist type (Mohs surgery, paediatric dermatology, dermatopathology), add a routing note with the specific clinical question, and submit. The escalated case appears in the specialist's queue with the original submission intact and the routing note attached.

Specialist review creates a structured consultation note linked to the original case. The original provider is notified when the specialist review is complete and can see the consultation note alongside their own working notes before finalising the patient response. The consultation note is retained as part of the case record with the same audit trail and retention requirements as the original clinical documentation.

Escalation history is visible within the case timeline, provider, escalation reason, specialist assigned, response time, and outcome. This creates the documentation needed for clinical governance review and quality assurance audits. Access control ensures that escalated cases are visible to the receiving specialist but that only the assigned provider and specialist can access the full case PHI, applying the HIPAA minimum necessary standard throughout the escalation workflow.

HIPAA technical safeguard implementation for dermatological image data, which has specific compliance considerations because images are inherently identifiable PHI when they include visible facial features, tattoos, or distinctive skin characteristics, even when metadata is stripped. Images are stored as FHIR Binary resources rather than in generic object storage, so access is governed by the same role-based access control and audit logging as structured clinical data.

Storage uses AES-256 encryption at rest on HIPAA-eligible AWS S3 or GCP Cloud Storage buckets, with Business Associate Agreements executed with every infrastructure provider that handles image PHI. Pre-signed URLs with short expiry windows (typically 15 minutes) control temporary access to image files, so images are never publicly accessible and URL sharing doesn't create an access control gap. Image metadata, including EXIF data that can include location coordinates, is stripped at submission before storage.

Retention policy enforcement applies HIPAA's minimum requirements: clinical records retained for the period required by state law (typically 7--10 years for adult patient records, longer for paediatric records). Automated retention policy enforcement flags records approaching the deletion window for review rather than deleting automatically, because clinical context may require extended retention beyond the standard period. Audit logs capture every image access event, who accessed which case, at what time, from which IP, and are retained for a minimum of 6 years per HIPAA requirements.

Integration with the dermatology-specific EHRs most commonly deployed in US practices. Nextech EHR integration uses the Nextech API for patient demographics, appointment scheduling, and clinical note write-back. Modernizing Medicine EMA (Electronic Medical Assistant) integration uses the EMA API for patient record access, encounter creation, and prescription workflows, EMA's dermatology-specific data model includes structured fields for lesion location, morphology classification, and treatment response that map cleanly to the clinical data we capture in the asynchronous intake.

For practices on Epic, we use FHIR R4 with SMART on FHIR OAuth 2.0 for authorisation. Each completed teledermatology case writes back to the patient's Epic chart as a FHIR Encounter resource with a linked FHIR DocumentReference containing the provider's consultation note, so the teledermatology interaction appears in the patient's longitudinal record without manual transcription. FHIR DiagnosticReport resources carry structured findings where the clinical workflow generates them.

For practices on legacy systems that predate FHIR, HL7 v2 messaging through an integration engine (Mirth Connect or Azure Health Data Services) handles patient demographic sync, encounter creation, and results delivery. Integration scope and complexity is scoped during discovery, the clinical data flow required (read-only patient demographics vs. bidirectional structured note write-back) determines the implementation approach.