Proposal for medical/health/lifesci vocab covering US Healthcare insurance networks #1062
Comments
danbri
added
the
schema.org vocab
I started out btw thinking this should be added to a common health-lifesci extension. Am now thinking it is better for now in its own (healthplan) while we check if other countries might need similar. Can always integrate later. Anyway, drafting is as a 'pending' extension.
|
We should maybe think about a health insurance vocabulary with the terms used across various insurance providers not only healthcare insurance. For healthcare specificity this would not be many terms as they just use the diseases terminology/coding systemes (like ICDxx, CPT, etc) together with few linking properties (btw some of them we found in schema.org/Offer). The US seems very specific but am sure we can find convergence with europeans plans ~Marc |
|
Just lobbing notes over for a tangential (?) use case (and links to links) from https://westurner.org/opengov/us/index#healthcare-gov-hhs-cmms (2015-02) (... https://westurner.org/redditlog/#comment/c93pfhx (2013-03)
|
|
Interesting! Keep it up and keep us posted. thanks @westurner |
|
nope, that's just talk. these look great, thanks!
|
|
This schema is well-defined, required by U.S. government regulation, and is already in use. So Version 1.0 should be as close to identical to the official schema that the CMS agency requires as Schema.org would allow.
|
|
Thanks for the useful background David. I'll copy that into the issue description above too. |
|
Hi there! Scrubbing in. :) I really like the Benefits sub-type -- an optional section but critical nontheless. In the U.S., there are two areas of use cases of relevance:
Thanks, |
|
This is published in pending.schema.org, therefore leaving issue open for ongoing discussion. |
|
Location of latest pending Schema.org for reference, based on CMS/CCIIO mandated QHP schema:
@henryweimd, feel free to weigh in |
|
would it be possible to allow MedicalOrganization, or the specific types of Dentist, Hospital, Pharmacy, or Physician to show acceptance of HealthInsurancePlan or HealthPlanNetwork as a property? |
How should these edges between {MedicalOrganizations,} and {HealthInsurancePlan, HealthPlanNetwork} indicate {datePublished, effectiveDate, }?
|
. |
|
@mfhepp I think we need to step back and realize that there is a need for acceptedPaymentMethods above the level of Offer and that can also help @westurner answer his questions. I think often that consumers are worried or wondering if an Organization allows for an acceptable form of payment. https://schema.org/acceptedPaymentMethod But this is not only an issue with MedicalOrganizations but anywhere you have a monetary transaction. We can probably tackle the question more broadly and simply at the Organization level for smaller organizations...."this Org accepts Cash, Credit, Aetna, or BlueCrossBlueSheild" ...but for larger organizations each particular Service Offered might want to have different AcceptablePaymentMethods ? @mfhepp There's the need to handle simple cases better for small organizations like a Chinese Restaurant that only accepts CASH. (why even deal with Offer here, that's a pain...ALL of their offers are CASH only, but we have no nice way for developers to code this.) A complex case, a radiological scan at a medical clinc that only accepts Credit or HealthInsurance {acceptable insurance: "Aetna, BCBS") @westurner But to answer your question directly, I think just expanding the expected values under https://schema.org/acceptedPaymentMethod and adding "healthinsurance" might work for MedicalOrganizations. ...but I have serious doubts that keeping acceptedPaymentMethod only under Offer (and not also Organization) will be broadly helpful to consumers that do a search for "doctors in my area that accept CheapoCowboys Insurance" |
|
Probably not quite as elegant as folks think. Blue Cross Blue Shield sounds as though it's one payment type -- like Visa or Mastercard. But sadly it's not: it's just a company/organization. There are literally thousands of unique contracts between US health insurers and hospitals/doctors/providers that the data model needs to support. The temptation is to say "yeah but let's just try to make it easy first" which is a big technical debt incurred up-front, since insurance contract eligibility isn't just about payment but rather also whether the patient's health plan offers certain agreed-upon discounts for that health care provider. Think of the discount contract more like thousands of virtual discount clubs where you might get a 5% discount at Hertz depending on your employer or affiliation group, but need a long CDP code to specify that discount.
… On Jan 29, 2017, at 09:20, Thad Guidry ***@***.***> wrote:
@mfhepp I think we need to step back and realize that there is a need for acceptedPaymentMethods above the level of Offer and that can also help @westurner answer his questions.
I think often that consumers are worried or wondering if an Organization allows for an acceptable form of payment. https://schema.org/acceptedPaymentMethod But this is not only an issue with MedicalOrganizations but anywhere you have a monetary transaction. We can probably tackle the question more broadly and simply at the Organization level for smaller organizations...."this Org accepts Cash, Credit, Aetna, or BlueCrossBlueSheild" ...but for larger organizations each particular Service Offered might want to have different AcceptablePaymentMethods ?
@mfhepp There's the need to handle simple cases better for small organizations like a Chinese Restaurant that only accepts CASH. (why even deal with Offer here, that's a pain...ALL of their offers are CASH only, but we have no nice way for developers to code this.)
A complex case, a radiological scan at a medical clinc that only accepts Credit or HealthInsurance {acceptable insurance: "Aetna, BCBS")
@westurner But to answer your question directly, I think just expanding the expected values under https://schema.org/acceptedPaymentMethod and adding "healthinsurance" might work for MedicalOrganizations.
...but I have serious doubts that keeping acceptedPaymentMethod only under Offer (and not also Organization) will be broadly helpful to consumers that do a search for "doctors in my area that accept CheapoCowboys Insurance"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@henryweimd Its more simple for the Consumer use case. There are different use cases.
If everyone is saying that this proposal will take care of both #1 and #2 .. then great ! |
|
Currently, Hospitals and patients are communicating in the simple form. i.e. they are advertising that they accept Aetna or Blue Cross, etc… and patients are searching for providers in their area who accept the same.
Examples: https://www.wellspan.org/provider-directory/provider-details/Adnan-Malik-MD-FACC-Cardiology-Gettysburg-PA/11111746
http://doctors.rush.edu/details/1167/ra-id-abdulla-pediatric_cardiology-chicago
I feel Mr. Guidry’s recommendation to add https://schema.org/acceptedPaymentMethod to Organizations with "healthinsurance" would be more than acceptable for these situations as they are now.
From: Henry Wei, MD [mailto:notifications@github.com]
Sent: Sunday, January 29, 2017 10:29 AM
To: schemaorg/schemaorg <schemaorg@noreply.github.com>
Cc: Glen Skelton <glen.skelton@connectcorp.com>; Comment <comment@noreply.github.com>
Subject: Re: [schemaorg/schemaorg] Proposal for medical/health/lifesci vocab covering US Healthcare insurance networks (#1062)
Probably not quite as elegant as folks think. Blue Cross Blue Shield sounds as though it's one payment type -- like Visa or Mastercard. But sadly it's not: it's just a company/organization. There are literally thousands of unique contracts between US health insurers and hospitals/doctors/providers that the data model needs to support. The temptation is to say "yeah but let's just try to make it easy first" which is a big technical debt incurred up-front, since insurance contract eligibility isn't just about payment but rather also whether the patient's health plan offers certain agreed-upon discounts for that health care provider. Think of the discount contract more like thousands of virtual discount clubs where you might get a 5% discount at Hertz depending on your employer or affiliation group, but need a long CDP code to specify that discount.
On Jan 29, 2017, at 09:20, Thad Guidry ***@***.******@***.***>> wrote:
@mfhepp I think we need to step back and realize that there is a need for acceptedPaymentMethods above the level of Offer and that can also help @westurner answer his questions.
I think often that consumers are worried or wondering if an Organization allows for an acceptable form of payment. https://schema.org/acceptedPaymentMethod But this is not only an issue with MedicalOrganizations but anywhere you have a monetary transaction. We can probably tackle the question more broadly and simply at the Organization level for smaller organizations...."this Org accepts Cash, Credit, Aetna, or BlueCrossBlueSheild" ...but for larger organizations each particular Service Offered might want to have different AcceptablePaymentMethods ?
@mfhepp There's the need to handle simple cases better for small organizations like a Chinese Restaurant that only accepts CASH. (why even deal with Offer here, that's a pain...ALL of their offers are CASH only, but we have no nice way for developers to code this.)
A complex case, a radiological scan at a medical clinc that only accepts Credit or HealthInsurance {acceptable insurance: "Aetna, BCBS")
@westurner But to answer your question directly, I think just expanding the expected values under https://schema.org/acceptedPaymentMethod and adding "healthinsurance" might work for MedicalOrganizations.
...but I have serious doubts that keeping acceptedPaymentMethod only under Offer (and not also Organization) will be broadly helpful to consumers that do a search for "doctors in my area that accept CheapoCowboys Insurance"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#1062 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYNqZxS5nb1iDPKjGG8xhj4bk5pqwSffks5rXLBPgaJpZM4H65x0>.
|
|
Thanks. As a primary care physician as well as a recovering ex-health
insurance executive, I'd be happy to discuss the reality of the situation
live or directly with anyone interested. While public-facing ads from
doctors and hospitals often try to use the short-hand to clear through
basic higher-level categories of coverage (if you don't take Aetna you're
unlikely to take any of the flavors of Aetna), there are a lot of false
positives happening in the U.S. market now due to this very
misunderstanding. And well-meaning hospitals will still err on the side of
getting more patients in, even if they can't pay for it.
The user experience as a result is quite terrible -- the patient sees the
provider and gets a bill that their insurer doesn't cover i.e. they have
Aetna but not the specific network that the patient signed up for. Or the
patient has scheduled an appointment weeks in advance, only to discover the
night beforehand or the day of the visit that they have Aetna, but not the
specific network of the plan.
So again I'd exhort us to find a path that maybe permits both the
bad-answer-early approach, but perhaps a hierarchical schema that then can
accomodate the "real" answer when those data are available, e.g. specific
health plan ID and/or provider network ID, and not the brand of the
overarching company.
Another quick and unnecessary analogy: this is like asking whether a
restaurant has Coke in the southern parts of the United States. Coke is
generically used to describe all sodas. In slightly less crazy cases it's
used to describe Coca-Cola products, but then you need to specify Diet Coke
vs regular Coke (e.g. Coca-Cola Classic). In the case of health insurance,
imagine that Coca-Cola stocked ~100-200 difference lines of soda, all
vaguely similar but surprisingly different when it came to, say, cancer
treatment and other edge cases of low volume but high meaning.
The 80/20 or Pareto rule doesn't always apply well in health care, for the
very issue that health insurance is ideally something that few people have
to use. So we may need to thinking about design that is robust enough to
handle edge cases because healthcare, itself, is concerned with optimizing
the care for relatively rare edge cases like cancer, mental health,
specialist visits, and so forth, and not the bulk of healthy people who
don't interact with the system other than routine subacute care.
On Mon, Jan 30, 2017 at 9:51 AM Glen-Skelton <notifications@github.com>
wrote:
… Currently, Hospitals and patients are communicating in the simple form.
i.e. they are advertising that they accept Aetna or Blue Cross, etc… and
patients are searching for providers in their area who accept the same.
Examples:
https://www.wellspan.org/provider-directory/provider-details/Adnan-Malik-MD-FACC-Cardiology-Gettysburg-PA/11111746
http://doctors.rush.edu/details/1167/ra-id-abdulla-pediatric_cardiology-chicago
I feel Mr. Guidry’s recommendation to add
https://schema.org/acceptedPaymentMethod to Organizations with
"healthinsurance" would be more than acceptable for these situations as
they are now.
From: Henry Wei, MD ***@***.***
Sent: Sunday, January 29, 2017 10:29 AM
To: schemaorg/schemaorg ***@***.***>
Cc: Glen Skelton ***@***.***>; Comment <
***@***.***>
Subject: Re: [schemaorg/schemaorg] Proposal for medical/health/lifesci
vocab covering US Healthcare insurance networks (#1062)
Probably not quite as elegant as folks think. Blue Cross Blue Shield
sounds as though it's one payment type -- like Visa or Mastercard. But
sadly it's not: it's just a company/organization. There are literally
thousands of unique contracts between US health insurers and
hospitals/doctors/providers that the data model needs to support. The
temptation is to say "yeah but let's just try to make it easy first" which
is a big technical debt incurred up-front, since insurance contract
eligibility isn't just about payment but rather also whether the patient's
health plan offers certain agreed-upon discounts for that health care
provider. Think of the discount contract more like thousands of virtual
discount clubs where you might get a 5% discount at Hertz depending on your
employer or affiliation group, but need a long CDP code to specify that
discount.
> On Jan 29, 2017, at 09:20, Thad Guidry ***@***.***<mailto:
***@***.***>> wrote:
>
> @mfhepp I think we need to step back and realize that there is a need
for acceptedPaymentMethods above the level of Offer and that can also help
@westurner answer his questions.
>
> I think often that consumers are worried or wondering if an Organization
allows for an acceptable form of payment.
https://schema.org/acceptedPaymentMethod But this is not only an issue
with MedicalOrganizations but anywhere you have a monetary transaction. We
can probably tackle the question more broadly and simply at the
Organization level for smaller organizations...."this Org accepts Cash,
Credit, Aetna, or BlueCrossBlueSheild" ...but for larger organizations each
particular Service Offered might want to have different
AcceptablePaymentMethods ?
>
> @mfhepp There's the need to handle simple cases better for small
organizations like a Chinese Restaurant that only accepts CASH. (why even
deal with Offer here, that's a pain...ALL of their offers are CASH only,
but we have no nice way for developers to code this.)
>
> A complex case, a radiological scan at a medical clinc that only accepts
Credit or HealthInsurance {acceptable insurance: "Aetna, BCBS")
>
> @westurner But to answer your question directly, I think just expanding
the expected values under https://schema.org/acceptedPaymentMethod and
adding "healthinsurance" might work for MedicalOrganizations.
>
> ...but I have serious doubts that keeping acceptedPaymentMethod only
under Offer (and not also Organization) will be broadly helpful to
consumers that do a search for "doctors in my area that accept
CheapoCowboys Insurance"
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<
#1062 (comment)>,
or mute the thread<
https://github.com/notifications/unsubscribe-auth/AYNqZxS5nb1iDPKjGG8xhj4bk5pqwSffks5rXLBPgaJpZM4H65x0>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1062 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACLkdyCUJeU4-TCPO3rvy9UaIvrleqQvks5rXfjxgaJpZM4H65x0>
.
|
|
I want to remind all that we have yet to make a clear disambiguation between the physician-person and the physician-organization. Within any physician-organization, the individual physician-persons may or may not participate with an insurance carrier. There is also the issue of the NPI number. CMS issues unique separate NPI numbers to the physician person and the physician organization. So, we seriously need to make it crystal clear to webmasters what In the wild Even the example cited above by @Glen-Skelton for Dr. Malik uses the Insurance and Clinical Trial vocabularyAnd it's not just an issue with the scalability of Insurance vocabulary. We will run into this What now?The chickens have come home to roost ;-) Are we going to address this via adding a new |
|
Regarding the misuse of Physician as pointed out here: There is a large demand for “quality” metrics in the healthcare field by consumers, but since Person cannot be marked up with “ratings data,” however, sites have been resorting to using Physician since it falls under Organization which it can be.
From: Leeza Rodriguez [mailto:notifications@github.com]
Sent: Thursday, February 2, 2017 3:26 PM
To: schemaorg/schemaorg <schemaorg@noreply.github.com>
Cc: Glen Skelton <glen.skelton@connectcorp.com>; Mention <mention@noreply.github.com>
Subject: Re: [schemaorg/schemaorg] Proposal for medical/health/lifesci vocab covering US Healthcare insurance networks (#1062)
I want to remind all that we have yet to make a clear disambiguation between the physician-person and the physician-organization. Within any physician-organization, the individual physician-persons may or may not participate with an insurance carrier. There is also the issue of the NPI number<https://npiregistry.cms.hhs.gov>. CMS issues unique separate NPI numbers to the physician person and the physician organization. So, we seriously need to make it crystal clear to webmasters what Physician represents. To refresh:
In the wild
Physician <https://schema.org/Physician> is currently defined at schema.org as an organization/ Physician's office, and not the person. As I have been saying for some time, there is already questionable/incorrect usage of Physician in the wild<#807 (comment)>. In fact, some of the most reputable portals and institutions are using Physician in their Physician directory to represent the physician person, instead of the organization entity.
Even the example cited above by @Glen-Skelton<https://github.com/Glen-Skelton> for Dr. Malik<https://www.wellspan.org/provider-directory/provider-details/Adnan-Malik-MD-FACC-Cardiology-Gettysburg-PA/11111746> uses the Physician markup when this page is clearly about the physician-person, identification of his MedicalSpecialty, and the organization entities he is associated with. If there is any doubt, the source code references his INDIVIDUAL NPI number<https://npiregistry.cms.hhs.gov/registry/provider-view/1699829234>, and not an organization NPI. So, in a nutshell, AFAICT, some webmasters are (incorrectly) using Physician to represent the physician-person in their physician directory.
Insurance and Clinical Trial vocabulary
And it's not just an issue with the scalability of Insurance vocabulary. We will run into this Physician person vs organization identity crisis with Clinical Trial vocabulary too. More details found here <#280 (comment)> about those distinctions, as well as my thoughts of how MedicalSpecialty lineage truly starts with the physician person , and not the physician organization.
What now?
The chickens have come home to roost ;-)
Are we going to address this via adding a new Profession type to the core (ala @thadguidry<https://github.com/thadguidry> suggestion<#1410> and @JarnoVanDriel<https://github.com/jarnovandriel>'s proposal<https://docs.google.com/document/d/151dHBdBcVJ6cW9uqT3ARrmLDFO9gPPSnh87ed4KC844/edit#heading=h.7vq5hoq3p6xi> ) , via other mechanisms<#492 (comment)> in the medical extension, or something else?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1062 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AYNqZ3AtB90UcT4ZPLLih0dhxyxI_eP4ks5rYjvhgaJpZM4H65x0>.
|
|
@Glen-Skelton Individual physicians are being rated all over the web. It is not just their organization entity which is being rated. We shouldn't be forcing webmaster to use work arounds to model this in their markup. And in any event, the other issues still hold. |
|
This issue is being tagged as Stale due to inactivity. |
github-actions
bot
added
the
no-issue-activity
|
What are the use cases here? Has https://schema.org/HealthInsurancePlan solved for the use cases? |
github-actions
bot
removed
the
no-issue-activity
This issue tracks a proposal from David Pourtnoy et al. There is a public Google doc at https://docs.google.com/document/d/1LNew5OEon4uir2D5Zzp0AkUPA7c9nO8reJ_M1pOy-3s/edit?usp=gmail
We should note that the design is explicitly US-centric, and that this can be accommodated within schema.org through our 'hosted extensions' mechanism.
@vholland worked on a draft design last year. This has been somewhat discussed alongside the ongoing work on cleanup of existing schema.org medical/health vocabulary (#492) but note that it is a distinct project, even if it is ultimately published within the same extension (e.g. under health-lifesci.schema.org).
Background (from @dportnoy)
"This schema is well-defined, required by U.S. government regulation, and is already in use. So Version 1.0 should be as close to identical to the official schema that the CMS agency requires as Schema.org would allow."
The text was updated successfully, but these errors were encountered: