Integrating Stratosphere’s PACT with PointClickCare via HL7

The Architecture in One Sentence

PointClickCare (PCC) generates HL7 v2 events as clinical and administrative actions happen in the EHR, and forwards those events over an HL7 interface to PACT’s HL7 listener — where each message is hashed, anchored to a tamper-evident ledger, and made available for independent verification, without PACT ever becoming the system of record for clinical data itself.

That separation of roles matters. PCC stays the authoritative EHR. PACT never edits, stores clinical narrative long-term, or presents itself as a documentation system. It functions purely as an integrity layer sitting downstream of PCC, receiving a copy of the event stream and proving that whatever PCC says happened, happened exactly that way and hasn’t been altered since.

Why HL7 Is the Right Transport for This

HL7 v2 is showing its age — it predates HTTPS, it isn’t natively encrypted, and its pipe-delimited format is nobody’s favorite thing to debug at 2 a.m. But it remains the lingua franca of long-term and post-acute care interfacing, and PCC’s event model (ADT admission/transfer/discharge events, ORU result events, MDM document events) maps naturally onto it. For a facility that already has ADT and clinical event feeds running to a pharmacy system or a hospital interface, adding PACT as another HL7 subscriber is a much smaller lift than standing up a net-new API integration from scratch.

One thing to verify before building this: PointClickCare has been shifting its primary integration model toward FHIR/REST APIs, and its developer terms restrict accessing PCC data outside the sanctioned web service APIs. Facilities and vendors still running HL7 v2 interfaces with PCC typically do so through an approved interface engine or a legacy ADT/clinical feed that was provisioned before that shift, rather than a raw, self-service HL7 connection. Before assuming this architecture is available out of the box, confirm with your PCC account team whether your facility’s tenant has an active HL7 interface enabled, or whether the event stream needs to be bridged from PCC’s FHIR API into HL7 before it reaches PACT.

How the Integration Works, End to End

1. Event occurs in PCC

A nurse finalizes a medication administration record, an incident report is completed, a care plan is updated, or a resident is transferred between units. PCC’s interface engine packages that event into an HL7 v2 message — an ADT^A02 for a transfer, an MDM^T02 for a finalized document, an ORU^R01 for a result, depending on the event type.

2. PCC forwards the message to PACT’s HL7 listener

PACT hosts an HL7 server (typically listening via MLLP — Minimal Lower Layer Protocol — the standard TCP wrapper for HL7 v2 traffic) at an endpoint provisioned for the facility. PCC’s outbound interface is configured to route the relevant event types to that endpoint, the same way it would route to a pharmacy or lab interface today.

Because HL7 v2 isn’t encrypted at the message level, this connection should run over a TLS-wrapped MLLP session or through a VPN tunnel between PCC’s interface engine and PACT’s listener — never over the open internet in plaintext. This is a standard requirement for any HL7 interface carrying ePHI, and it applies here the same as it would for any other PCC interface partner.

3. PACT parses, hashes, and anchors

On receipt, PACT’s listener parses the message into its segments (MSH, EVN, PID, PV1, and whatever event-specific segments apply), and computes a cryptographic hash of the record content. That hash is anchored to PACT’s tamper-evident ledger along with a timestamp and message metadata (event type, sending facility, message control ID) — establishing an independent, externally verifiable fingerprint of the event as PCC reported it, at the moment it arrived.

Critically, PACT does not need to become a long-term clinical data store to do this. It can retain only what’s necessary to support verification (the hash, the anchor, and enough metadata to match a fingerprint back to a specific PCC record) while the full clinical detail remains where it belongs — in PCC.

4. Acknowledgment back to PCC

Standard HL7 practice applies: PACT returns an ACK (or NACK, if the message failed parsing or validation) so PCC’s interface engine can confirm successful delivery and handle retries the same way it does for any other downstream system. This keeps the integration well-behaved from PCC’s side — it looks and behaves like any other interface partner in PCC’s existing interface engine configuration.

5. Verification, on demand

When a surveyor, auditor, or internal QA reviewer needs to confirm a record’s integrity, the workflow is: pull the record from PCC as usual, then ask PACT to re-hash the current content and compare it against the anchored fingerprint from the original HL7 event. A match proves the record hasn’t changed since PCC originally reported it. A mismatch is flagged immediately, and because the anchor lives outside of PCC, that mismatch can’t be caused — or hidden — by anyone editing records inside PCC after the fact.

Which PCC Events Are Worth Sending

Not every HL7 event PCC can generate needs to go to PACT — that would create unnecessary volume and noise. The events worth anchoring are the ones that carry audit weight:

• ADT events (admission, transfer, discharge) — establishes an immutable timeline of a resident’s movement through the facility, useful for census disputes and survey timelines.
• MDM document events — finalized progress notes, incident reports, care plan revisions. This is the category that matters most for falsification concerns, since it’s the category surveyors scrutinize hardest.
• ORU result events — lab and diagnostic results, useful for confirming that clinical decisions were made on the basis of results that weren’t altered after the fact.

Routine, low-stakes traffic (scheduling updates, non-clinical administrative messages) generally isn’t worth anchoring and can be filtered out at the interface engine level before it ever reaches PACT.

Implementation Checklist

• Confirm HL7 availability with PCC. Verify with your PointClickCare account or interface team whether your facility’s environment still supports outbound HL7 v2 interfacing, or whether the event data will need to be sourced through PCC’s FHIR API and translated to HL7 (or handed to PACT directly via API) before reaching PACT’s listener.
• Scope the event types. Decide with your compliance and clinical informatics teams which HL7 event types actually need integrity anchoring, rather than routing the entire firehose of PCC traffic.
• Secure the transport. Require TLS-wrapped MLLP or a site-to-site VPN between PCC’s interface engine and PACT’s HL7 listener — this is non-negotiable for anything carrying ePHI.
• Test in a non-production environment first. Use PCC’s sandbox/test environment to validate message formatting, segment mapping, and ACK/NACK handling before pointing production traffic at PACT.
• Define the verification workflow. Decide, before your next survey rather than during it, exactly how staff will pull a verification result from PACT and present it alongside the PCC record — this shouldn’t be improvised in front of a surveyor.
• Plan for interface monitoring. Like any HL7 interface, this one needs monitoring for dropped connections, queue backlogs, and failed message delivery — a gap in the anchoring stream is itself something an auditor could ask about.

The Net Effect

Done well, this integration means every clinically or administratively significant event PCC records gets an independent, tamper-evident fingerprint the moment it happens — without PCC’s workflow changing for the staff entering the data, and without PACT ever needing to hold itself out as a second EHR. The facility ends up with the same PointClickCare charting experience clinical staff already know, plus a standing, independently verifiable answer to the question every auditor eventually asks: how do you know this record wasn’t changed after the fact?