Hacker News new | past | comments | ask | show | jobs | submit | dalben's comments login

Can't say for Las Vegas, but we do here (in Belgium). There's a dedicated responsibility during mass casualties to distribute leaving ambulances over hospitals, also taking into account hospital specialties and facilities, such as a burn unit. The closest hospital is usually skipped because victims who self-transport will usually go there.


This is common in the US, and I would assume in every other modern healthcare system.


Interesting that he had to do so much thinking and improvising. I'm an EMT in Belgium, and every hospital here has to have plans for mass casualty events. Ambulance bays are built to be transformed into a triage ward, spare beds are kept close, often there's a dedicated command room, ...


As Eisenhower put it: "Peace-time plans are of no particular value, but peace-time planning is indispensable."

In other words, the act of planning means you're better prepared for specific contingencies, so you'll hopefully be better prepared for whatever actually happens, but some improvisation will always be necessary.


100%. As another wise man once said, "everybody has a plan until they get punched in the mouth."

The planning may be directly applicable in whole, is almost certainly applicable in part but in my opinion the main thing is that it provides a template for thinking about what things are important and which are expendable when you're operating in an environment with a greater tolerance for risk.


There is a rather large difference to having plans and dealing with an actual incident. Not to bicker, but a dedicated command room sounds like a fun plan but the opposite of what was needed in the incident described in this story.


Events like this are much more common than you may think, though rarely as severe as this shooting. From fires at retirement homes and even at an ED once, bus crashes, WWII bombs surfacing during construction, floods… it almost becomes routine. I can assure you the plans are not built not academics but are refined through experience. And in a weird way, disaster response almost becomes routine.


Yeah it seemed very hands on , running around finding issues, getting people on them etc.


At the Luton airport they have these big "mass casualty event" supply boxes on the walls. Presumably full of supplies to provide efficient first aid after such an event on the spot.

As I was writing this comment I learned that they were inspired by a bombing which happened in Brussels: https://www.shponline.co.uk/fire-safety-and-emergency/mascal...

One of those things you hope will never need to be used. But if it is ever needed it will be very handy.


With respect from Canada, I doubt you are seeing many incidents with 200+ gunshot victims in Belgium



I stand corrected


We do not! The US is a loved destination for training placements and exchanges because you can see so many stabbings and shootings in one shift.

However, a shooting is just one type of mass casualty event.


> I'm an EMT in Belgium

It always happens eventually in discussions like this. "I'm from <country in Europe> and I don't get why y'all are so stupid, unlike us."

The US healthcare system is worthy of critique for many things, most of all cost, but the quality of care is just as good as every other western nation. Doctors are quite skilled, just like they are in Belgium I assume. And of course hospitals plan for mass casualty events. All of them, I bet, if they have an ER.


I wonder if OpenStreetMap has historical information easily available and easily queryable. It'd be interesting to see the evolution of the number of benches in cities and parks. My feeling is that they have been disappearing in my area, and it feels harder to find good spots to sit and read a book.


(That would be a semantic error rather than syntactic error, no?)


I don’t know, English is not even my second language.


Likely due to reporting. It seems that news articles are used as the source. If the DJI marketing team maintaining this map is English, it's probably easier to find or verify English news stories. Most fire departments in Belgium now have a few drones as part of a pilot project, and I found a (Dutch) news article of an incident last month were they were used, even though the map is blank for Belgium.


While there is population stabilisation, there's also changing demographics. Immigration, more single people (or people waiting until later in life to move in together), and an aging population that prefers to live at home will still put pressure on the housing market even though we are over "peak child" - that was the conclusion I reached when I researched the housing market in my EU country and why I decided to buy an apartment this year, coupled with low mortgage rates.


>buy an apartment this year, coupled with low mortgage rates

Where were there low mortgage rates this year?


Huh, thanks for the tip. I'll try this next time I meet a patou!


I am a SWE (IANAL) with a post-grad degree in GDPR/DPO, and while I had only time for a cursory read, I must say it hits a lot of nails on the head! A breath of fresh air in times of so much GDPR misinformation.

From what I remember, the ePrivacy-GDPR cookie mismatch (consent as the only allowed legal basis for cookies) is due to ePrivacy being older than the GDPR and not intentional.

Article 5 (Principles) is always a good mention - just having a legal basis is not enough, you always need to respect these principles (such as lawfulness, fairness and transparency).

The dig at pseudonomyzation not being enough is great. It's a personal pet peeve of mine. Pseudonomized data is still personal data!

The GDPR does not prescribe how to anonymize data. It just says "as long as someone can identify a person, then it's personal data." For example, you might think that aggregating based on city is enough to anonymize, but my nephew was at one point the sole person living in a village - that would have directly identified him. Likewise, stripping the last octet of IP addresses might not be enough if I personally own a /24. It's all about context.

The biggest thing I personally learned, was that any solution claiming to be "GDPR proof" probably is not compliant.


Author of the article here! (I tried to submit it but HN rejected it)

I started researching this last weekend, reading through the GDPR, the ePrivacy Directive, and tons of related court rulings (with the help of Google Translate). 2002/58/EC and EC 2016/679 is engrained into my brain now. I was so nervous releasing to the public, but I breathed a sign of relieve after reading your comment.


This is one of my pet peeves of GDPR! Your nephew and IP Octet cases are very extreme edge cases that we shouldn't build policy around if there are major drawbacks to including them. It's bad there is ostensibly no compliant way to count anonymized unique users in Europe under the current framework.


I don't think there is any way to reliably count unique users without collecting an inappropriate level o f personal data. Even tracking unique devices requires significantly undermining privacy.

This simply isn't data companies should be allowed to collect without meaningful consent.


A half-baked idea I had while reading the article was to use bloom filters:

User visits the site. On the backend, check if their IP+UA is in the bloom filter or not. If not, increase the unique visitor counter and add them to the filter.

Perhaps the filter would need to be preseeded with dummy data to protect the privacy of the first few visitors.


Not a bad idea, but IP addresses are personal data too.


I think this is a great idea


This is effectively what the “GDPR compliant” providers mentioned in the article are already doing, namely, a one-way hash of the IP+UA. One of the points of the article is that this is non compliant, since you need to transmit the IP+UA to do this calculation to begin with.


But do they store individual IP+UA hashes, or do they mush them together in a bloom filter or a HyperLogLog data structure?

In the first case, it could be argued they still store personally identifiable information (for a limited time, but still). In the second case I think it would be harder to argue the probabilistic data structure with lots of hashes mushed together still constitute personally identifiable information.

> One of the points of the article is that this is non compliant, since you need to transmit the IP+UA to do this calculation to begin with.

IP + UA gets transmitted to the first-party server already. They already have it. The question becomes – is it OK to anonymize this PII we already received for one purpose (serving the web page), to use it for another purpose also (counting unique visitors).


> IP + UA gets transmitted to the first-party server already. They already have it. The question becomes – is it OK to anonymize this PII we already received for one purpose (serving the web page), to use it for another purpose also (counting unique visitors).

Maybe I'm missing your point, but in the situation we're talking about (so-called "GDPR compliant" analytics), if I set up one of these services on my website, the user's IP+UA are transmitted to a 3rd party, for the sole purpose of analytics including counting unique visitors. My understanding is that this is quite different in the eyes of the GDPR from the question you posed, and is almost always not going to be compliant.


I was thinking about the article author's case where they were looking at options for implementing unique user tracking for themselves, on their own server.


The most interesting fact is that there's now a postgrad degree in gdpr



It depends. For last-mile delivery and public transport with small vessels, that may not be the case.

The city of Ghent was eyeing autonomous small crafts as "water taxis", and a big shipping provider wanted to do last-mile(s) delivery for shops, restaurants, and small parcel pickup points along a river. For the latter case, the vessel would still be manned, but instead of having to navigate, that person could sort and prepare parcels for delivery.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: