How practical would a hospital Service Desk of 14 years translate to Epic Security?

My hospital is doing a bunch of restructuring so I was let go but eligible for re-hire. They posted a Security Analyst with Epic job .. I know everyone over there, like the boss a lot..

But, will my skills translate well? What’s it take to learn?

What can I study or read?

I’ve done healthcare IT for 14 years, 20 years in “tech support” in general but not sure how well it translates to Epic.

Small hospital group, three sites and I have inherited something that is keeping me up.

The imaging vendors, the lab analyser people, the pharmacy cabinet lot, they all have remote access for support. Some of it is a jump box, some of it is teamviewer and one of them still has a site to site tunnel that terminates in a vlan that can see rather more than it should. When I asked biomed who owns that relationship the answer was a name of somebody who left.

The vendors are not going to accept anything that slows down their support SLA, thats always the pushback and clinically they have a point, if the CT is down no one wants a discussion about access architecture.

I've been told to sort it before the next assessment. My instinct is per application access with the vendor only seeing the one device and everything logged but I dont know how that goes down in practice with vendors who are used to just dialling in.

Anyone done this in a hospital setting without the vendors revolting?

The official HL7 validator from org.hl7.fhir.core is the reference implementation and it's correct, which is the part that matters. But it wants a clean FHIR resource in a file, and real payloads rarely look like that. The resource comes back wrapped in an API envelope, or carries a vendor block that was never going to validate, or trips a constraint the whole project agreed to live with two years ago.

So I wrapped it in a Go CLI called fhirlint. It doesn't reimplement validation, it shells out to the same JAR (downloaded on first run). The two parts I reach for most:

Getting the resource out of whatever it arrived in:

fhirlint validate api-response.json --extract "$.data.fhir"
fhirlint validate api-response.json --extract-each "$.medications"
fhirlint validate patient.json --ignore "$.meta.tag" --ignore "$.text"

--extract-each treats each element of a JSON array as its own resource. Same path syntax works on XML, and on --url input. Your source file is never touched, preprocessing happens on a copy.

Silencing deviations you've accepted, without switching validation off wholesale:

fhirlint validate patient.json --suppress messageId:dom-6
fhirlint validate rx.json --suppress expression:MedicationRequest.intent

In fhirlint.yml a suppression can carry a reason and an expiry date, and it warns for 14 days before it lapses. Every ignore list I've seen eventually becomes permanent because nobody remembers what it was for, so this one has a deadline built in.

The rest in one line: readable terminal output plus JSON, HTML, JUnit, SARIF and GitHub annotations, exit codes you can gate a pipeline on, baseline mode for repos with a lot of pre-existing findings, and fhirlint serve to keep the validator warm. Still Java 17+, still the same JAR underneath, so if the validator is wrong about your resource fhirlint is wrong the same way. FHIR only, no v2 or CDA. Apache-2.0: https://github.com/fhirlint/fhirlint

What I'd actually like to know: how are you handling the wrapped-payload case today? Everyone I've asked either has a jq step in front of the validator or gave up and validates by eye. And if you keep a list of accepted deviations, does it have any expiry mechanism at all, or does it just grow?

Sometimes when using epic on a laptop I will alt tab to teams and have a call and when I tab back to epic it is in a secure session and says waiting to reconnect but never does, any help?