Hi I'm Nnamdi.
This series walks through a project I built around one question: how does a patient's data get from a hospital system that speaks H...
For further actions, you may consider blocking this person and/or reporting abuse
Great write-up, Nnamdi! 😄
What stood out to me wasn’t just the HL7-to-FHIR architecture, but how documenting the system helped you uncover a failure that normal testing had missed.
The Tenacity RetryError issue is a perfect example of why individually correct components don’t necessarily produce a reliable system.
One thought for the SQS migration: idempotency and duplicate handling will be just as important as durable delivery, especially when retries can replay patient admission events.
I also appreciated your honesty about the Prometheus alert that couldn’t actually fire. A control existing in configuration doesn’t mean it works in practice.
Looking forward to Part 2. Keep it up! 👏
Thank you, Mustafa! 😄
The idempotency point is the one I needed, and it's sharper than durable delivery because the queue can't solve it for me.
Half of it FHIR already answers. A transaction Bundle entry takes ifNoneExist, so the Patient can be a conditional create keyed on the NHS number: create only if no patient carrying that identifier exists. That half is easy, because NHS number is a stable natural key.
The Encounter is the hard half. I can't put it on patient identity, since two admissions for the same patient are legitimately two Encounters. So the question becomes what identifies this admission event, and the answer isn't in the FHIR layer at all.
Which is where your point bites. I went and read the SQS documentation properly before replying. FIFO deduplication runs on a five-minute minimum interval, and AWS states that if a message is resent with the same deduplication ID after that interval, SQS can't detect it. So the queue handles transport duplicates and nothing beyond them.
That leaves two different problems with the same name. Duplicate delivery is the queue redelivering something I already processed, and MSH-10, the message control ID, catches that. Duplicate event is the trust engine resending the same admission with a fresh control ID after an interface restart or a manual resend, and MSH-10 doesn't catch it at all, because at every layer it looks like a new message.
The second one is what would put two admissions on a patient record, and I don't have a settled answer yet. Probably a business key on the Encounter identifier built from NHS number, admission timestamp and the point of care in PV1. I'd want to test that against real engine behaviour before claiming it works.
And yes on the alert. PDSCircuitOpen is the same class as the dead-letter rule. It reads like a property of the system, and it's a property of the configuration. Part 4 fixes it, and this time I'm writing the test that proves it fires before I write the rule. 🙏
That’s a great distinction, Nnamdi! 😄
You’re absolutely right that message deduplication and clinical event deduplication are two different problems.
One small thought: I’d be careful about including PV1 location in the business key, since patients can move between wards during the same admission.
If the source system provides a stable visit identifier (such as PV1-19), that might be a stronger starting point, scoped to the assigning authority.
And I really like your approach of testing against actual engine behaviour before declaring the design reliable.
Looking forward to seeing how this evolves! 👏
You're right, and the failure is worse than drift.
A transfer arrives as its own event. An A02 carries a different location for the same admission so the key would change mid-stay. The control I'd built to prevent duplicate Encounters would have manufactured one on every ward move.
PV1-19 is the better answer for a reason worth naming, because it's the thread running through everything I've been writing. A composite key built from demographics and location is me inferring an identity. PV1-19 is the sending system stating one. I've spent sixty-odd posts learning to prefer the stated thing over the derived thing, and I still reached for the derived one here.
One limitation I found while checking the spec. PV1-19 is optional in v2.5.1, CX, cardinality 0..1, so I can't assume it's populated. Some implementations carry visit identity in PID-18 Patient Account Number instead, and PV1-50 Alternate Visit ID exists as well. So the real design question isn't which field to use. It's what the pipeline does when the field it expects is empty, and whether it fails closed or quietly falls back to something weaker.
That's not answerable from the standard. It needs real engine traffic, which is the same conclusion I keep arriving at.
Thank you for this one. This is the second time in a week you've stopped me from building something that looked correct. 🙏
That’s exactly the kind of architectural thinking I enjoy, Nnamdi! 😄
And I think you’ve reached the most important question: not just which identifier to trust, but what happens when that identifier is missing. Sometimes the safest design decision is to admit that we don’t have enough information rather than invent an identity that looks reliable. I’ve really enjoyed this exchange. We’re all learning from each other’s perspectives, and that’s what makes these discussions valuable.
Looking forward to the next part, my friend! 👏
Nnamdi, good luck with your new series! By the way, @xulingfeng , what about you? Which series are you planning to start?
Thank you! This has been sitting in my GitHub repository for a long time, so I thought it was time to share it with anyone interested in healthcare systems, particularly interoperability, career switchers, and healthcare professionals looking to explore the technology behind the systems they use.
I often receive questions from healthcare professionals about how these systems work behind the scenes and how AI can help improve them. I created this series specifically to answer these questions, break down the underlying concepts, and make healthcare technology and interoperability more accessible to everyone interested in the field.
I hope this will be a useful resource for anyone curious about the intersection of healthcare, technology, interoperability, and AI.
Hahaha, the hidden thread of this new series lies within my Thirty-Six Stratagems stories. Keep it a secret for now 🤣
I can’t wait for the your new series.
🤣Just in my mind now,hahaha
New series🎉