CLIENT: Northfork Valley Health🇺🇸United States

Sutura - HIPAA-Compliant Patient Data Hub over HL7 and FHIR

Patient Data Hub for a US Regional Health System

Designed and built a clickable patient data hub for a US health system running Epic, Oracle Health, athenahealth and eClinicalWorks: a live monitor for every HL7 v2, FHIR and HIE feed, one matched enterprise patient with a provenance-tagged record, and a duplicates queue where a person decides every uncertain match.

Scope of Work
Product design, UI build and clickable demo
Industry
Health Data / Patient Data Hub
HealthcareEnterprise
Compliance & Certifications
HIPAA Privacy RuleHIPAA Security Rule42 CFR Part 221st Century Cures Act (information blocking)HL7 v2HL7 FHIR R4 and US CoreSMART on FHIRHL7 DS4P security labelsTEFCACMS Conditions of Participation

Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.

Impact

5 Screens
Clickable end to end

Dashboard, interface monitor, patient search, the unified patient record with 7 tabs, and the potential duplicates queue with side-by-side pair review.

6 Sources
In one patient timeline

The demo record joins Epic, Oracle Health, athenahealth, Quest, Sectra PACS and the state HIE. Every item carries a source chip and opens a provenance panel with its local and standard code.

Two-Person
Rule on risky actions

A production replay needs a second approver who is not the requester, and merging twin or newborn records waits for a second reviewer. Every merge and replay needs a reason.

22 Interfaces
Realistic demo data

12 sources over HL7 v2, FHIR R4, C-CDA and HIE query, 6 alerts, 18 synthetic patients, 20 coded clinical items and 12 duplicate tasks.

The Problem

Northfork Valley Health grew by acquisition, and its patient data grew apart. One patient seen at an Epic hospital, the Oracle Health hospital and an athenahealth practice had three medical record numbers and three partial charts. The interface team ran more than 140 point-to-point HL7 interfaces with no shared dashboard, so a failed feed was usually found by a clinician asking where a result had gone, and nobody could say how many duplicate patient records existed.

Our Solution

Sutura takes in HL7 v2 feeds, FHIR R4 APIs, C-CDA documents and HIE queries from every source, matches each record to one enterprise patient and serves a unified, provenance-tagged record to authorised clinicians. Integration engineers watch every feed in one monitor, data integrity staff work a duplicates queue, and every access has a stated basis.

The Challenge: One Patient, Many Systems

Northfork runs four hospitals, 38 owned clinics and an affiliated network of about 220 independent practices on four different EHRs, plus reference labs, imaging and health information exchanges. Joining that data is a technical problem, a patient safety problem and a privacy problem at once.

Feeds That Fail Silently

ADT, results, orders, documents, scheduling and immunization feeds arrive as HL7 v2 over MLLP, alongside FHIR R4 pulls and HIE queries. With no shared view, a silent interface or a burst of unmapped codes went unnoticed until a result was missing on the ward.

No National Patient Identifier

The US has no national patient id, so matching relies on demographics and local MRNs. A wrong merge puts one person's results in another's chart, so uncertain pairs need a person, and twins and newborns need extra care.

Sensitive Data With Its Own Rules

Substance use disorder records are protected by 42 CFR Part 2, and state laws add rules for HIV, mental health, genetic testing, minors and reproductive health. These records had been kept out of the shared record because there was no safe way to segment them.

Access That Must Be Explained

The HIPAA Security Rule expects access controls, emergency access procedures and audit controls, and the Cures Act limits withholding data without a recognised exception. The privacy office could not produce one access report for a patient across systems.

Our Approach: From Interoperability Rules to a Clickable Hub

01

Spec and Rules Research

Mapped 10 user roles, 36 screens (32 staff screens, a 3-screen developer portal and an embedded viewer launched from the EHR), 5 slide-over panels and the data model for sources, interfaces, messages, enterprise patients, match rules, duplicate tasks, sensitive categories, care relationships, break-the-glass events and access events. Wrote down the rules the design follows: the HIPAA Privacy and Security Rules, business associate agreements, Cures Act information blocking, HL7 v2, FHIR R4 with US Core and SMART App Launch, TEFCA, 42 CFR Part 2, HL7 security labels and CMS event notifications.

02

Clickable Demo on a Production UI Kit

Built 5 key screens on a production dashboard kit: the dashboard with system status, KPIs, interface health tiles and work that changes by role, the interface monitor with baselines, warning reasons, a 24-hour throughput chart and replay requests, patient search with care relationship badges and break-the-glass, the unified record with timeline, results grouped by LOINC and medications collapsed by RxNorm, and the duplicates queue with merge, not the same person and needs more information. All actions run on local state.

03

What a Production Build Adds

An interface engine such as InterSystems Health Connect or Rhapsody, a FHIR server under the hosting BAA, live connections to Epic, Oracle Health, athenahealth, eClinicalWorks, Quest, Labcorp, the PACS, the state HIE and national networks, referential matching, NLM terminology content, SSO with MFA, hash-chained audit and access logs exported to the security team, and the remaining screens: message search, the dead letter queue, merge history, matching rules, the privacy pages, data quality, the API gateway, reports, settings, the developer portal and the embedded SMART viewer.

Why It Works: Every Fact Traced, Every Access Explained

Every Fact Shows Where It Came From

Each item on the unified record carries a source chip such as "Epic · North" or "HIE" and opens a provenance panel with the source system, message or API reference, received and recorded times, the local code, the mapped standard code and the mapping version applied.

Failed Feeds Surface Before Anyone Asks

A status chip on every page counts healthy, warning and down interfaces. Each interface is measured against its hourly baseline, and a warning row states its reason, such as "No message for 22 min, expected every 5 min" or an unmapped local code behind a rising error rate.

Uncertain Matches Go to a Person

Pairs in the review band are shown side by side with each field's agreement and weight in the score, plus recent clinical items from both records. Twins carry a caution badge, a merge needs a reason and a surviving id, and "not the same person" stops the pair being raised again.

Access Has a Basis, Sensitive Data Stays Quiet

Search shows whether the user has a care relationship, and opening a record without one goes through break-the-glass with a reason that the privacy office reviews. The record states its access basis, and withheld data shows only a neutral banner that never names the category.

Logo
Oceanlab

Enterprise Software Engineering - Human + AI

Languages

Locations

Global Headquarters

21 Merchant Road, 3rd Floor, Singapore 058267

Main corporate office and leadership operations

North America Office

548 Market Street, PMB 12345, San Francisco, CA 94104

Client operations and business development

India Office

402 Shivalik Shilp II, SG Highway, Ahmedabad 380015

Engineering and delivery center

© 2026 - Copyright. All Rights reserved Oceanlab