This issue is being nudged due to inactivity.

cause was removed after a cleanup effort as described here (making https://schema.org/MedicalCause orphaned?)
#2435
So examples should be updated.

These examples tripped me up as well when I was working on preparing an implementation, especially as causeOf is (still) available.

@danbri, as cause was removed, what does this mean for the inverse property causeOf? Should this then be removed too? Or is this an example where MedicalCause would always lead to MedicalCondition and thus causeOf is a valid property, but MedicalCondition can have many causes and would become ambiguous?

Great, thanks for making that clear that it is OK to keep causeOf.

More important would be to identify anyone who actually does something with
this markup…

Glad you asked! Allow me to go off topic!

I think anyone trying to use health-lifesci schema in their website is only doing this convinced that this has some "SEO benefit", or possible future SEO benefit. The SEO community is always looking for an authoritative answer on till what extent structured data types apart from officially documented are supported/processed by Google (Given Google's market share, if any other search engine would support more, due to cost you'd still not implement it. For Baidu, it does not support Schema.org).

So we hear this:

Mueller notes that Google does not crawl structured data to learn more about the page.
https://www.searchenginejournal.com/google-structured-data-rarely-gives-us-unique-information/389729/

But then 2 days later Gary Illyes says:

but we do extract all kinds of structured data it's not just what the Rich Result testing tool
validates, but pretty much any structured data that you put on the page
https://twitter.com/thetafferboy/status/1335361054654783492

So, that leaves us pretty much in the dark till what extent it helps with "entity discovery". But, how how much this would be needed at all now and in the next 5 years. If you insert your medical text into https://aws.amazon.com/comprehend/medical/ you definitely feel less compelled to do all the classification manually.

Then we also have the situation where Google is directly working with partners to get medical information into the KG (in supported countries such as US, BR, IN, ID): https://support.google.com/websearch/answer/2364942?hl=en
This data is not connected to the structured data at all. The KG from Mayo Clinic on "heart attack" in the US is much more complete than the mark-up on MedicalCondition:
https://www.mayoclinic.org/diseases-conditions/heart-attack/symptoms-causes/syc-20373106

My background in this: I am working on a hospital chain that is migrating CMS and improving implementation of structured data. I started to notice the state of maintenance, especially after looking at MedicalSpecialty. This made me apprehensive to do a full fledged implementation that later may see many revisions apart from not generating much benefit at all ever or at first.

I also read your response in #2894 and the discussion in #1598. It seems to me a case of chicken and egg. No adoption as no support from Google and vice versa.

Cheers,
Aldert

P.S. defining a medical condition with all of it's symptoms, preventions, possible treatments etc etc is already hard enough in text, let alone then getting this structure into a database. And, if anyone has done this hard work, what would then stop me from scrape this off this website and publish it as my own, maybe augmented with my own data?

@Dutch-Al

Search engines philosophy toward promoting and sharing health information

The publishing and sharing of health information that has the potential to save lives should always be openly shared. Google, Bing, and others have long acknowledged this and contribute back to that cause. Google has demonstrated their philosophy and stance on this in my eyes personally by allowing the world to query much of the healthcare sector as a public good. https://console.cloud.google.com/marketplace/browse?filter=solution-type:dataset&filter=category:health

I think it's acceptable that a general search against a search engine like Google for a medical condition can be done nowadays and users are presented some quick facts and somewhat authoritative information, while presenting well to users that those quick facts are

For informational purposes only. Consult your local medical authority for advice.

SEO of health information with a profit agenda

As health information as a public good, I don't ever look or find appealing that health information is considered IP (intellectual property). For those looking to profit off of health information, there is nothing for us to stop them from that. At the same token, its very unlikely that well structured data on pages from entities that seem to have a "profit agenda" will likely ever show up highly ranked in search engine results. Case in point, https://www.google.com/search?q=heart attack will never show those kinds of non-authoritative sites even in the first 10 pages of results on any search engine. It is well known and established that trying to SEO for any "health information" with a mindset for a "profit agenda" is a waste of time. Those that provide "health information" for the public good are always ranked much more highly and considered a valuable resource of knowledge toward possibly saving human lives.

In Summary:

I think the benefit for any "hospital chain" to offer deeply structured data of medical conditions is probably not needed. This is already covered by scientific and research communities.
Much more beneficial I think would be treatment and care facilities such as a "hospital chain" could ensure that structured data about any specialities, equipment, testing facilities or capacity they have in treatment of conditions is much more beneficial for the public good.

MedicalProcedure, MedicalTherapy, and MedicalTest are much more important for any "hospital chain" to let the public know what availableService's they offer along with highlighting any particular MedicalSpecialty that they are well equipped and certified to help the public with should be a focus for those types of entities that can provide care and treatment.

@thadguidry thanks for weighing in on this. I agree with your philosophical POV.

Justifying implementation costs

The SEO aspect remains unanswered. There is no evidence that MedicalCondition or MedicalProcedure, -Therapy, -Test are consumed by Google. When I read Dan's comments like below, I don't get convinced otherwise.

More important would be to identify anyone who actually does something with this markup…
@danbri <#2878 (comment)>

Context - This is a proposal from Google based on our experience consuming schema.org HealthAspectEnumeration markup and working with health-related content. If it were accepted, it could (this is a tricky area...) make it easier for us and others to understand the different kinds of health aspects addressed by a piece of Web content.
@danbri <#2799 (comment)> (Emphasis mine)

If it costs $30k to implement these schemas and, more importantly, another X amount to maintain it, how would I justify such costs? Meanwhile it could still make sense to modularize the actual content so that the schemas eventually could be used (and for improved display of content to visitors).

Examples in the wild

MedicalProcedure has been implemented on less websites than MedicalCondition (if I do a source code search with https://publicwww.com/). BuiltWith tracks usage of MedicalCondition and MedicalSpecialty. Less than 100 of all top 1 million websites use these schemas: https://trends.builtwith.com/framework/MedicalCondition-Schema. BuiltWith does not support the more obscure Medical schemas.

Even though well known sites are using the schema (pennmedicine.org, franciscanhealth.org, CDC.gov, MayoClinic.org, NHS.uk) ), the question remains, did it help anyone that they added the schema mark-up on the front-end of the website? AFAIK, the medical condition KG is not populated by Google crawling the JSON data, but relies on a specific partnership. Evidence also shows that Mayo Clinic KG does not match the data inside MedicalCondition on their webpage.

No standardized implementation

NHS has also created modularized content and is now available in the KG (https://www.nhs.uk/conditions/heart-attack/)

Their approach to the Medical schema vastly differs from Mayo Clinic with a heavy reliance on HealthTopicContent instead. MedicalCondition is found under about of MedicalWebPage:

KG ahead of Schema.org for MedicalProcedure

The KG below provides important topics of the procedure that are not part of a property under https://schema.org/MedicalProcedure. The accordion could offer different subtopics depending on the procedure.

Still uncertain on benefit for mankind

MedicalProcedure, MedicalTherapy, and MedicalTest are much more important for any "hospital chain" to let the public know what availableService's they offer along with highlighting any particular MedicalSpecialty that they are well equipped and certified to help the public with should be a focus for those types of entities that can provide care and treatment.

All such information is important for the public and it can be modularized accordingly (for which the schemas are a big inspiration). But the public interfacing with website does not require Schema at all... So I fail to understand why you say it is important (to implement). You'd implement Schema so that the public interfacing with a search engine quicker/better finds the answer through improved matching of content with query.

I can appreciate some vagueness on actual support or, more importantly, the benefit to prevent overpromising. I am not looking for special ranking boosts or fancy search features. But I do need to understand if search engines are helped in any way (no matter how little) with the medical structured data, or whether Googlebot blatantly ignores it and will always do so. As long as this is unclear, how can I become an advocate for implementing Medical Schemas and waste my time, others people time, and money for no good?

Thanks for the initial reply on this so quickly. It will help me for now this week and looking forward to further details in September, have a great break :)

I would tread lightly here, the medical profession is notorious for revamping their coding every couple of years. The privacy issues are probably already mute though, Google seems to know which maladies I'm interested before I even search for the term.

Outside the scope of Google's use of medical structured data, sites that apply this markup are also interested in the internal reuse of their structured data knowledge graph. The specificity permitted by bilateral relationships is useful. I would like to know more about the rationale that dictates when inverse properties are allowed, and when they are not (as with causeOf vs. cause).

This is still needed, it was removed during the health-lifesci cleanup.

<span itemprop="cause" itemscope itemtype="https://schema.org/MedicalCause">

Example code block from https://schema.org/MedicalCondition (truncated)

  <h1><span itemprop="name">Stable angina</span>
    (<span itemprop="alternateName">angina pectoris</span>)</h1>
  The most common causes are
  <span itemprop="cause" itemscope itemtype="https://schema.org/MedicalCause">
    <span itemprop="name">atherosclerosis</span>
  </span>
  and
  <span itemprop="cause" itemscope itemtype="https://schema.org/MedicalCause">
    <span itemprop="name">spasms of the epicardial artery</span>
  </span>.
  <br>
  The initial treatment for stable angina is usually drug therapy  with
  <span itemprop="possibleTreatment" itemscope itemtype="https://schema.org/Drug">
    <span itemprop="name">aspirin</span>
  </span>,
  <span itemprop="possibleTreatment" itemscope itemtype="https://schema.org/DrugClass">
    <span itemprop="name">beta blockers</span>
  </span>,
  <span itemprop="possibleTreatment" itemscope itemtype="https://schema.org/DrugClass">
    <span itemprop="name">ACE inhibitors</span>
  </span>, and/or
  <span itemprop="possibleTreatment" itemscope itemtype="https://schema.org/Drug">
    <span itemprop="name">nitroglycerine</span>
  </span>.
</div>```