Feature Proposal - Voting - Tag:insurance:health

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature Proposal - Voting - Tag:insurance:health

Mhairi O'Hara
Voting is now open for the proposed feature insurance:health

"Indicates the type of health insurance accepted at a health facility"


Please read the page, then add your vote and any additional comments here:


--
Mhairi O'Hara
Technical Project Manager
@mataharimhairi



Humanitarian OpenStreetMap Team
Using OpenStreetMap for Humanitarian Response & Economic Development
web
 |      twitter
 |      facebook
 |      donate

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - Voting - Tag:insurance:health

dieterdreist


sent from a phone

On 1. Aug 2019, at 22:18, Mhairi O'Hara <[hidden email]> wrote:

Voting is now open for the proposed feature insurance:health

"Indicates the type of health insurance accepted at a health facility"



the situation is similar to the healthcare equipment proposal, the proposal only mentions a key and there is no guidance which values are expected. As you are writing about “types” of insurances I would expect these types listed and explained.

Additionally looking at taginfo gave me the impression that the insurance:*=* system is used with different semantics (e.g. insurance:car=yes will likely not be intended to mean: this place accepts car insurances). 

My suggestion would be something more explicit/descriptive and not colliding with existing usage (none of the insurance* tags seems documented, so you better avoid them, unless you’re sure what the people who applied them had in mind). 

E.g. 
healthcare:insurance_types=semicolon list
or
accepted_insurance_types=
or
accepted_health_insurance_types=...

Admittedly they’re all rather bulky.

If you don’t mention the types you might get people adding the names of individual insurance companies or products.

Cheers Martin 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - Voting - Tag:insurance:health

Graeme Fitzpatrick
& as I mentioned some time ago, the example you have used on the proposal page:  https://www.openstreetmap.org/node/2060334624#map=19/51.33315/6.56633  appears to be the Customer Service office of a Health Insurance company:  https://www.meine-krankenkasse.de/ ?

In other words, nothing at all to do with hospital, treatment or what patients are accepted where.

That's a bit like listing the head office of a motor insurance firm as a car repair centre!

Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - Voting - Tag:insurance:health

Warin
On 02/08/19 08:26, Graeme Fitzpatrick wrote:

> & as I mentioned some time ago, the example you have used on the
> proposal page:
> https://www.openstreetmap.org/node/2060334624#map=19/51.33315/6.56633 
> appears to be the Customer Service office of a Health Insurance
> company: https://www.meine-krankenkasse.de/ ?
>
> In other words, nothing at all to do with hospital, treatment or what
> patients are accepted where.
>
> That's a bit like listing the head office of a motor insurance firm as
> a car repair centre!

I think this is a payment thing.

A firm may accept payment from certain credit cards and not others. Same
thing for a medical facility.
As such it could use the existing tagging, not create a new one.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - Voting - Tag:insurance:health

Joseph Eisenberg
In reply to this post by Graeme Fitzpatrick
I'm afraid I can't vote to approve the current draft of this proposal.
I haven't investigated the name of the key (insurance:health) too
much, but it would be good to use a key that does not have any risk of
confusion.

My main concern is that it is not clear how the value should be used.
The suggested examples are =private, =public, or =no - only the last
is usually useful. It would be better to suggest that each country or
region create values that match the most common and important
insurance options.

For example, here in Papua Indonesia there are 2 public insurance
systems, Papua Sehat from the province, and the new national BPJS
Kesehatan which is a private-public corporation. It would be much more
helpful to tag these two values rather than "public", especially since
BPJS-Kesehatan is only quasi-public.

In the USA, "Medicare" and "Medicaid" would be somewhat helpful (much
more than just "public"), but you would really want State-specific
values like Medi-Cal (California) and Oregon Health Plan (Oregon). I'm
not sure about the insurance market in Africa, which is the main focus
of this whole proposal, but I suspect similar things will develop over
time.

Joseph

On 8/2/19, Graeme Fitzpatrick <[hidden email]> wrote:

> & as I mentioned some time ago, the example you have used on the proposal
> page:
> https://www.openstreetmap.org/node/2060334624#map=19/51.33315/6.56633
> appears to be the Customer Service office of a Health Insurance company:
> https://www.meine-krankenkasse.de/ ?
>
> In other words, nothing at all to do with hospital, treatment or what
> patients are accepted where.
>
> That's a bit like listing the head office of a motor insurance firm as a
> car repair centre!
>
> Thanks
>
> Graeme
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

ebel
On 02/08/2019 02:02, Joseph Eisenberg wrote:
> My main concern is that it is not clear how the value should be used.
> The suggested examples are =private, =public, or =no - only the last
> is usually useful. It would be better to suggest that each country or
> region create values that match the most common and important
> insurance options.

One could take inspiration from the road classification system and use
country code prefixes for the value? `insurance:health=<country
code>:<value>`. Private health insurance in Ireland is different from US
private health insurance, so `insurance:health=IE:private` vs
`insurance:health=US:private`.

You can read it as “The health insurance here has the value of
“private” _as the term is understood in the USA_”. It could be extend to
state level (`US:CA:whatever`).


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

Warin
On 02/08/19 16:18, Rory McCann wrote:

> On 02/08/2019 02:02, Joseph Eisenberg wrote:
>> My main concern is that it is not clear how the value should be used.
>> The suggested examples are =private, =public, or =no - only the last
>> is usually useful. It would be better to suggest that each country or
>> region create values that match the most common and important
>> insurance options.
>
> One could take inspiration from the road classification system and use
> country code prefixes for the value? `insurance:health=<country
> code>:<value>`. Private health insurance in Ireland is different from US
> private health insurance, so `insurance:health=IE:private` vs
> `insurance:health=US:private`.
>
> You can read it as “The health insurance here has the value of
> “private” _as the term is understood in the USA_”. It could be extend
> to state level (`US:CA:whatever`).

It is possibly that some will only accept certain insurance firms and
reject others. I am thinking of insurance firms that run some medical
facilities.




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

ebel
On 02/08/2019 08:42, Warin wrote:
> It is possibly that some will only accept certain insurance firms and
> reject others. I am thinking of insurance firms that run some medical
> facilities.

We use subkeys for payment types (`payment:american_express=no`),
wouldn't this work for insurance companies? `insurance:vhi=no`, or
`insurance:health:vhi=no`?


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

Warin
On 02/08/19 17:26, Rory McCann wrote:
> On 02/08/2019 08:42, Warin wrote:
>> It is possibly that some will only accept certain insurance firms and
>> reject others. I am thinking of insurance firms that run some medical
>> facilities.
>
> We use subkeys for payment types (`payment:american_express=no`),
> wouldn't this work for insurance companies? `insurance:vhi=no`, or
> `insurance:health:vhi=no`?

My point, almost.
As the "insurance" is a method of payment it could be tagged
payment:health_care_fund=yes (substitute whatever insurance name you
want for "health_care_fund").

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

SimonPoole
In reply to this post by ebel

Am 02.08.2019 um 09:26 schrieb Rory McCann:
> On 02/08/2019 08:42, Warin wrote:
>> It is possibly that some will only accept certain insurance firms and
>> reject others. I am thinking of insurance firms that run some medical
>> facilities.
>
> We use subkeys for payment types (`payment:american_express=no`),
> wouldn't this work for insurance companies? `insurance:vhi=no`, or
> `insurance:health:vhi=no`?

The problem with this, just as with payment, that it creates a
(practically) unbounded list of keys, that rely on being able to do a
search on keys to be discoverable.

Simon


>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

Joseph Eisenberg
I’m normally not in favor of semi-colon separated values, but this seems like a situation where it is better, since there would be hundreds or thousands of keys otherwise.

eg =Medicare;Medicaid;Blue_Cross (USA)
=BPJS_Kesehatan;Papua_Sehat (Indonesia)

It will still be hard to keep this sort of data maintained, either way, in some countries, but it may work ok in places with only a handful of insurance options.

Joseph

On Fri, Aug 2, 2019 at 4:41 PM Simon Poole <[hidden email]> wrote:

Am 02.08.2019 um 09:26 schrieb Rory McCann:
> On 02/08/2019 08:42, Warin wrote:
>> It is possibly that some will only accept certain insurance firms and
>> reject others. I am thinking of insurance firms that run some medical
>> facilities.
>
> We use subkeys for payment types (`payment:american_express=no`),
> wouldn't this work for insurance companies? `insurance:vhi=no`, or
> `insurance:health:vhi=no`?

The problem with this, just as with payment, that it creates a
(practically) unbounded list of keys, that rely on being able to do a
search on keys to be discoverable.

Simon


>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

Warin
In reply to this post by SimonPoole
On 02/08/19 17:40, Simon Poole wrote:

> Am 02.08.2019 um 09:26 schrieb Rory McCann:
>> On 02/08/2019 08:42, Warin wrote:
>>> It is possibly that some will only accept certain insurance firms and
>>> reject others. I am thinking of insurance firms that run some medical
>>> facilities.
>> We use subkeys for payment types (`payment:american_express=no`),
>> wouldn't this work for insurance companies? `insurance:vhi=no`, or
>> `insurance:health:vhi=no`?
> The problem with this, just as with payment, that it creates a
> (practically) unbounded list of keys, that rely on being able to do a
> search on keys to be discoverable.

Unfortunately there can be no bound as new firms arrive. Possibly some old ones rename.

What is the solution? A rendering problem... and most will not use it.




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

dieterdreist
In reply to this post by SimonPoole


sent from a phone

> On 2. Aug 2019, at 09:40, Simon Poole <[hidden email]> wrote:
>
> The problem with this, just as with payment, that it creates a
> (practically) unbounded list of keys, that rely on being able to do a
> search on keys to be discoverable.



yes, but in practical terms you would know the name of your health insurance and could search explicitly for this, it wouldn’t matter that there will be an unbounded list of other keys as well.

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - Voting - Tag:insurance:health

Marc Gemis
In reply to this post by Mhairi O'Hara
I think this tag is useless for Belgium, but that does not mean it is useful in other countries.
Let me explain the Belgian situation, so perhaps you can help me here to decide whether it should be used or not.

Everybody in Belgium has public health insurance by one of the 4 "ziekenfondsen". Every health care provider works with them. In some cases, you have to pay the full amount upfront (e.g. dentist), and send the bill to your health care insurance to get some refunding. In other cases, the health care provider only charges you with the amount the public health insurance providers do not pay. (Think hospitals). Typically not the whole amount is refunded, but special tariffs apply for certain groups of people.

On top of that you can have a private insurance, which e.g. pay for a single room in a hospital. Sometimes the hospital will send the bill directly to them (*) in other cases you have to pay the remaining amount (not covered by public insurance), and send the bill to your private insurance. Depending on the case and your individual insurance plan, they will pay you back some amount. 

(*) it is still possible that you have to pay a small part of the total bill.

So I doubt it makes sense to map them in Belgium, what do you think ?

m

On Thu, Aug 1, 2019 at 10:19 PM Mhairi O'Hara <[hidden email]> wrote:
Voting is now open for the proposed feature insurance:health

"Indicates the type of health insurance accepted at a health facility"


Please read the page, then add your vote and any additional comments here:


--
Mhairi O'Hara
Technical Project Manager
@mataharimhairi



Humanitarian OpenStreetMap Team
Using OpenStreetMap for Humanitarian Response & Economic Development
web
 |      twitter
 |      facebook
 |      donate
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Subkeys like payment:*=yes/no? | Re: Country code value prefix? | Re: Feature Proposal - Voting - Tag:insurance:health

Mark Wagner
In reply to this post by Joseph Eisenberg

Won't work in the US, as values have a size limit of 255 bytes, and
there are more *insurance plans* than that in the US.  You might be
able to pack everything in by treating the value as a bitfield.

--
Mark

On Fri, 2 Aug 2019 16:52:22 +0900
Joseph Eisenberg <[hidden email]> wrote:

> I’m normally not in favor of semi-colon separated values, but this
> seems like a situation where it is better, since there would be
> hundreds or thousands of keys otherwise.
>
> eg =Medicare;Medicaid;Blue_Cross (USA)
> =BPJS_Kesehatan;Papua_Sehat (Indonesia)
>
> It will still be hard to keep this sort of data maintained, either
> way, in some countries, but it may work ok in places with only a
> handful of insurance options.
>
> Joseph
>
> On Fri, Aug 2, 2019 at 4:41 PM Simon Poole <[hidden email]> wrote:
>
> >
> > Am 02.08.2019 um 09:26 schrieb Rory McCann:  
> > > On 02/08/2019 08:42, Warin wrote:  
> > >> It is possibly that some will only accept certain insurance
> > >> firms and reject others. I am thinking of insurance firms that
> > >> run some medical facilities.  
> > >
> > > We use subkeys for payment types (`payment:american_express=no`),
> > > wouldn't this work for insurance companies? `insurance:vhi=no`, or
> > > `insurance:health:vhi=no`?  
> >
> > The problem with this, just as with payment, that it creates a
> > (practically) unbounded list of keys, that rely on being able to do
> > a search on keys to be discoverable.
> >
> > Simon
> >
> >  
> > >
> > >
> > > _______________________________________________
> > > Tagging mailing list
> > > [hidden email]
> > > https://lists.openstreetmap.org/listinfo/tagging 
> >
> > _______________________________________________
> > Tagging mailing list
> > [hidden email]
> > https://lists.openstreetmap.org/listinfo/tagging
> >  


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging