Cerner and other electronic medical records systems have, as a huge component of their operation, a scheme for ingesting HL7 data streams (and emitting them to

Cerner and other electronic medical records systems have, as a huge component of their operation, a scheme for ingesting HL7 data streams (and emitting them to other systems). It's likely the reference to ingestion in the article refers to that. Chaos-monkeying with those data streams is flat out a good idea when building robust HL7 IT systems. HL7 encodes a series of changes. For example, you might get records like this. at 2020-10-06T14:33:00 patient 144616 moved from Floor 6 Rm 603 Bed 2 to OR3 at 2020-10-06T15:47:00 patient 144616 moved from OR3 to Recovery 3 at 2020-10-06T18:20:00 patient 144616 moved from Recovery 3 to Floor 6 Rm 603 Bed 2 It's all state changes. Reconstructing the current state of affairs requires knowing which state was the latest for interesting object (patient, usually, but also maybe OR or other location in my trivial example). These HL7 records don't necessarily show up in chronological order either. Trouble is, preexisting chaos monkeys (bugs) in systems like these sometimes say to themselves "oops somebody lost sync, I better resync." Resyncing is done by resending a backlog of many days' worth of HL7 records to the unsuspecting consumer of those records. So anything that can be done, by Cerner or any other HL7-using system, continually to test the oddball edge cases involving loss of sync is a good idea. And, oh, yeah, everything in those records is protected health information. And often they're sent over ordinary TCP streams without encryption. Health care IT relies on firewalls big time. I don't think the linked article is written for most HN readers; it's written for Cerner CIOs and other in-the-trenches health care IT workers.