New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for medical/health/lifesci vocab covering US Healthcare insurance networks #1062

Open
danbri opened this Issue Mar 29, 2016 · 20 comments

Comments

Projects
None yet
8 participants
@danbri
Contributor

danbri commented Mar 29, 2016

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)

In November 2015, the US health agency Centers for Medicare & Medicaid Services (CMS) enacted a new regulatory requirement for health insurers who list plans on insurance marketplaces. They must now publish a machine-readable version of their provider network directory, publish it to a specified JSON standard, and update it at least monthly. Many major health insurance companies across the US have already started to publish their health plan coverage, provider directories and drug formularies to this standard.

"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."

danbri added a commit that referenced this issue Mar 29, 2016

Very rough draft started towards #1062.
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.
@twamarc

This comment has been minimized.

Show comment
Hide comment
@twamarc

twamarc Mar 30, 2016

Contributor

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

Contributor

twamarc commented Mar 30, 2016

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

@westurner

This comment has been minimized.

Show comment
Hide comment
@westurner

westurner Apr 2, 2016

Contributor

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)

Healthcare.gov (HHS CMMS)⬅

Homepage: https://www.healthcare.gov/
Wikipedia: https://en.wikipedia.org/wiki/HealthCare.gov
Docs: https://www.healthcare.gov/developers/
Twitter: https://twitter.com/HealthCareGov

  • TODO: create RDFa vocabulary for health plans
  • TODO: add RDFa to individual plan pages
  • TODO: search engine to index RDFa vocabulary
  • TODO: encourage carriers to add RDFa to describe their servcies
Contributor

westurner commented Apr 2, 2016

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)

Healthcare.gov (HHS CMMS)⬅

Homepage: https://www.healthcare.gov/
Wikipedia: https://en.wikipedia.org/wiki/HealthCare.gov
Docs: https://www.healthcare.gov/developers/
Twitter: https://twitter.com/HealthCareGov

  • TODO: create RDFa vocabulary for health plans
  • TODO: add RDFa to individual plan pages
  • TODO: search engine to index RDFa vocabulary
  • TODO: encourage carriers to add RDFa to describe their servcies
@twamarc

This comment has been minimized.

Show comment
Hide comment
@twamarc

twamarc Apr 2, 2016

Contributor

Interesting! Keep it up and keep us posted. thanks @westurner

Contributor

twamarc commented Apr 2, 2016

Interesting! Keep it up and keep us posted. thanks @westurner

@westurner

This comment has been minimized.

Show comment
Hide comment
@westurner

westurner Apr 2, 2016

Contributor

nope, that's just talk.

these look great, thanks!
On Apr 2, 2016 9:29 AM, "Marc" notifications@github.com wrote:

Interesting! Keep it up and keep us posted. thanks @westurner
https://github.com/westurner


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1062 (comment)

Contributor

westurner commented Apr 2, 2016

nope, that's just talk.

these look great, thanks!
On Apr 2, 2016 9:29 AM, "Marc" notifications@github.com wrote:

Interesting! Keep it up and keep us posted. thanks @westurner
https://github.com/westurner


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1062 (comment)

@dportnoy

This comment has been minimized.

Show comment
Hide comment
@dportnoy

dportnoy Apr 13, 2016

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.

dportnoy commented Apr 13, 2016

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.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 13, 2016

Contributor

Thanks for the useful background David. I'll copy that into the issue description above too.

Contributor

danbri commented Apr 13, 2016

Thanks for the useful background David. I'll copy that into the issue description above too.

@henryweimd

This comment has been minimized.

Show comment
Hide comment
@henryweimd

henryweimd Jun 3, 2016

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:

  1. Flagging the tier of the network of the provider (preferred status, often meaning a discount to the consumer)
  2. Signalling the availability of secure electronic health messaging as in HHS's Standards & Interoperability work here. http://wiki.siframework.org/Provider+Directories

Thanks,
Henry

henryweimd commented Jun 3, 2016

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:

  1. Flagging the tier of the network of the provider (preferred status, often meaning a discount to the consumer)
  2. Signalling the availability of secure electronic health messaging as in HHS's Standards & Interoperability work here. http://wiki.siframework.org/Provider+Directories

Thanks,
Henry

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 10, 2016

Contributor

This is published in pending.schema.org, therefore leaving issue open for ongoing discussion.

Contributor

danbri commented Aug 10, 2016

This is published in pending.schema.org, therefore leaving issue open for ongoing discussion.

@dportnoy

This comment has been minimized.

Show comment
Hide comment
@Glen-Skelton

This comment has been minimized.

Show comment
Hide comment
@Glen-Skelton

Glen-Skelton Jan 27, 2017

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?

Glen-Skelton commented Jan 27, 2017

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?

@westurner

This comment has been minimized.

Show comment
Hide comment
@westurner

westurner Jan 28, 2017

Contributor

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, }?

  • CreativeWork has dateCreated, dateModified, and datePublished
Contributor

westurner commented Jan 28, 2017

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, }?

  • CreativeWork has dateCreated, dateModified, and datePublished
@westurner

This comment has been minimized.

Show comment
Hide comment
@westurner

westurner Jan 28, 2017

Contributor

Location of latest pending Schema.org for reference, based on CMS/CCIIO mandated QHP schema:

.

Contributor

westurner commented Jan 28, 2017

Location of latest pending Schema.org for reference, based on CMS/CCIIO mandated QHP schema:

.

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Jan 29, 2017

@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"

thadguidry commented Jan 29, 2017

@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"

@henryweimd

This comment has been minimized.

Show comment
Hide comment
@henryweimd

henryweimd Jan 29, 2017

henryweimd commented Jan 29, 2017

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Jan 29, 2017

@henryweimd Its more simple for the Consumer use case. There are different use cases.

  1. Data sharing between MedicalOrganization and Insurance Providers (thought that was solved long ago, so don't see the reason for some of what the proposal brings forth, Consumers won't care about some of it)
  2. and sharing between those 2 entities and Search Engines / Consumers so that Consumers can make informed decisions. This issue is talking about use case #1 ...but I am saying there is a use case like # 2 to benefit consumers questions about which MedicalOrganization accepts which HealthInsurance/Plan(s).

If everyone is saying that this proposal will take care of both #1 and #2 .. then great !

thadguidry commented Jan 29, 2017

@henryweimd Its more simple for the Consumer use case. There are different use cases.

  1. Data sharing between MedicalOrganization and Insurance Providers (thought that was solved long ago, so don't see the reason for some of what the proposal brings forth, Consumers won't care about some of it)
  2. and sharing between those 2 entities and Search Engines / Consumers so that Consumers can make informed decisions. This issue is talking about use case #1 ...but I am saying there is a use case like # 2 to benefit consumers questions about which MedicalOrganization accepts which HealthInsurance/Plan(s).

If everyone is saying that this proposal will take care of both #1 and #2 .. then great !

@Glen-Skelton

This comment has been minimized.

Show comment
Hide comment
@Glen-Skelton

Glen-Skelton Jan 30, 2017

Glen-Skelton commented Jan 30, 2017

@henryweimd

This comment has been minimized.

Show comment
Hide comment
@henryweimd

henryweimd Jan 30, 2017

henryweimd commented Jan 30, 2017

@LeezaRodriguez

This comment has been minimized.

Show comment
Hide comment
@LeezaRodriguez

LeezaRodriguez Feb 2, 2017

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 Physician represents. To refresh:

In the wild

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. 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 for Dr. Malik 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, 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 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 suggestion and @JarnoVanDriel's proposal ) , via other mechanisms in the medical extension, or something else?

LeezaRodriguez commented Feb 2, 2017

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 Physician represents. To refresh:

In the wild

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. 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 for Dr. Malik 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, 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 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 suggestion and @JarnoVanDriel's proposal ) , via other mechanisms in the medical extension, or something else?

@Glen-Skelton

This comment has been minimized.

Show comment
Hide comment
@Glen-Skelton

Glen-Skelton Feb 2, 2017

Glen-Skelton commented Feb 2, 2017

@LeezaRodriguez

This comment has been minimized.

Show comment
Hide comment
@LeezaRodriguez

LeezaRodriguez Feb 2, 2017

@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.

LeezaRodriguez commented Feb 2, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment