See the data, not the patient
Terminologists, interface analysts, vendors and support teams need your HL7 and FHIR messages to do their work. None of them need to know whose results they are. PHI Shield sits between your messages and every screen, export and tool your people use, removes the identifiers HIPAA lists, and keeps everything the work depends on.
What stays, what goes
| Kept, because the work needs it | Removed or replaced |
|---|---|
| Local test code, name and coding system | Patient and family names, clinicians |
| Result value, unit, reference range, flags | Medical record number, replaced by a consistent token |
| Method, order and specimen type | Dates, reduced to the year, with relative time for troubleshooting |
| Sending facility and message type | Addresses, phone numbers, Social Security numbers |
| Sex, race and ethnicity | Visit, order, specimen and accession numbers, replaced by tokens |
| Patient class and hospital service | Room and bed, free-text notes |
| Insurance and guarantor information: always removed |
Built for interface messages, field by field
Most de-identification tools are built for documents. Interface work happens in segments and fields, so PHI Shield is built the same way: a rule for every HL7 v2 segment and field, and for every FHIR R4 resource and element that can carry an identifier.
- Deny by default. A segment or field that is not on the keep list is hidden, including custom Z-segments, until it has been reviewed.
- Consistent tokens. The same record number becomes the same token everywhere on the screen, so your team can see that two results belong to one patient or one order without seeing who or which.
- Relative time. Troubleshooting needs to know that a message was parsed three seconds after it arrived, not the date of someone's blood draw.
A reveal when troubleshooting needs it, and a record when it happens
Sometimes an interface problem needs the exact timestamp or the order number. PHI Shield allows a narrow reveal of dates and numbers for one message at a time, following the HIPAA limited data set rules: never names, record numbers or insurance. The person gives a reason, the reveal expires, and every reveal is written to a disclosure log you can review.
Proven on every release
A shield is only as good as its last test. Every release is run against synthetic messages that carry a planted identifier of every kind HIPAA lists, in every field that can hold one. If any of them appears on screen, the release fails. The verification report is yours to keep.
Ways to use it
| Service | What you get | Status |
|---|---|---|
| Shielded terminologist workspace | Map your local lab codes to LOINC, SNOMED CT and RxNorm in the CareCompile Terminologist view, with the shield on for every message your team opens | By contract |
| Shield gateway | HL7 v2 and FHIR in, a de-identified copy out, for vendors, test environments and analytics teams | In development |
| Shield assurance | The verification report for each release and a review of the disclosure log | With either service |
Where it stands today
PHI Shield runs in the CareCompile Terminologist view on synthetic traffic generated by MediFlow. Patient names, birth dates, addresses, phone numbers, Social Security numbers, insurance segments, attending clinicians and visit numbers are removed from every message view today. The token, date and free-text rules, the troubleshooting reveal and the release verification suite are being completed now. Engagements on your test or synthetic feeds are arranged by contract through CareCompile.
Tell us what you need to trust
Describe the workflow, interface or release you are validating. We define the synthetic patients, the interface profile, the expected outcomes and the evidence you get back. Access is by contract through CareCompile. Reply within one business day.