Physician Page Best Practices

Modified on Wed, 13 Mar 2024 at 03:49 PM

This Best Practices document is intended to support content creation teams. Our goal is to ensure pages contain the all content required for a robust knowledge graph in an HTML format that interfaces well with the Schema App Highlighter. Use this document as a checklist during the ideation and development phases of the template.


The Strategy and Typical Page Content sections are best used during high-level design and brainstorming phases. The Schema.org Properties & Associated Code section is best used during the template development and coding phase. This type is not independently eligible for a Rich Result, but there are possible related types to explore, including Review, and Profile Page.


TABLE OF CONTENTS


Strategy: Which “Type” to Target? 

Pages about people can be confusing when there are several possible Types to use. The content and intent of a page will be important in deciding which Type.


https://schema.org/IndividualPhysician

Best suited for: a page about a specific medical practitioner.

  • Particularly useful for clearly specifying expertise and affiliation information (e.g practicesAt, hospitalAffiliation, knowsAbout, medicalSpecialty, alumniOf).

Should not be used for: pages describing people who are not physicians (e.g admin, and/or paramedical professionals)


https://schema.org/Physician

Best suited for: independent physicians with a private practice and/or independent clinic.

  • IndividualPhysician is a subType of Physician and has more opportunities to clarify affiliation information.


https://schema.org/Profile Page

Best suited for: a page about a specific person in the context of authorship and content creation

  • Google’s documentation on Profile Page is geared towards content attribution in the context of ForumsGoogle Perspectives and other content such as Articles or Recipes.

Should not be used for: pages describing people who are not content creators.

  • Sometimes physicians and medical staff are also content creators. These cases should be discussed in more detail with your CSM to identify the best strategy.


https://schema.org/Person

Best suited for: multi typing to complement an IndividualPhysician or Physician Page.

  • A “Person” entity is a requirement for valid Profile Page markup.

Typical Page Content 

This section describes content commonly seen on this type of page. This checklist is best used during high-level design & brainstorming as you design templates & decide what information you intend to display.

  • Name, Honorific, and Educational Suffixes

  • Profile Picture    

  • Locations of Practice and/or Associations

    • Clinics

    • Hospital

    • Pharmacies

  • Maps

  • Contact information

  • Available Services

  • Specialty and areas of expertise

  • Accepted Insurance & Network ID

  • Professional Associations

    • Training

    • Education

    • Current Membership

  • Identification Codes (US NPI)

  • Reviews and Ratings

  • FAQs



Schema.org Properties & Associated Code Requirements

The second section of this document lists schema.org properties that may be used when mapping page content & generating JSON-LD for a Provider Page. Prerequisite code or content requirements will impact your ability to use certain schema.org properties as intended. 


If you have any questions, please contact your CSM or support@schemaapp.com.


Name, Honorific, and Educational Suffixes

Content & Code Requirements

Consider how easily names, honorifics, and suffixes can be programmatically isolated (e.g can educational suffixes be contained in a uniquely identifiable HTML element like <p id = “hon”>MD</p>)


Profile Picture

Content & Code Requirements

The image URL needs to be crawlable & indexable.


Locations of Practice and/or Associations (Clinics, Hospital, Pharmacies)

Content & Code Requirements

Utilize internal linking wherever possible! If the places mentioned have an entity home (i.e a Hospital location page), ensure that URL is present on the page to be referenced. Consider how easily unique location entities can be programmatically isolated (e.g contain all location info in a unique <div> rather than a series of undifferentiated <p> elements). 

 

Maps

Content & Code Requirements

The map URL should be accessible within the HTML document.  Nested #document data is inaccessible to the Schema App Highlighter.


Contact Information

Content & Code Requirements

Consider how easily contact information can be programmatically isolated (e.g. a telephone component including a unique value such as <p id = “tel”>).


Available Services

Code and Content Requirements

Utilize internal linking wherever possible! If the services mentioned have an entity home (i.e a Medical Condition page), then ensure that entity’s URL is present. Consider how easily the various TestProcedure, and Therapy entities can be programmatically isolated. E.g: contain all Test type info in a unique <div> rather than a series of undifferentiated <p> elements), in succession with Procedure and Therapies in their own unique divs.


Specialty and Areas of Expertise

Content & Code Requirements

This section will likely be targeted by OLER. Ideally, we want all entities targeted by the same property (e.g specialty, or knowAbout) to be contained within a single parent component.


Accepted Insurance Agencies

Content & Code Requirements

This section will likely be targeted by OLER. Ideally, we want all entities targeted by the same “mentions” property to be contained within a single parent component.


Professional Associations (Education, Training, Current Membership)

Content & Code Requirements

This section will likely be targeted by OLER. Ideally, we want all entities targeted by the same property (e.g alumniOf, or hasCredential) to be contained within a single parent component.


Identification Codes (US NPI, Insurance Network ID)

Typically, we advise that all the content in your schema markup must be present on your webpage. This advice is less relevant for identification codes and similar forms of metadata. It is reasonable to include these values in your markup without calling attention to them in your web content.


US NPI

A unique 10-digit identification number issued to health care providers in the United States by the Centers for Medicare and Medicaid Services.


Insurance Network ID

Use the name or unique ID of the Physician’s network.


Reviews and Ratings

Content & Code Requirement


Reviews and Ratings on a Provider landing page must be about the Physician themselves or the Services they provide. Nested #document data is inaccessible to the Schema App Highlighter. Ideally, Rating information should be aggregated and submitted on the Provider page itself. 


Individual Physician is a subtype of Organization and Google is clear that an Organization should not be eligible for self serving Reviews. Avoid including reviews from sites your Organization controls (e.g Google My Business). For more information, consult Google’s content requirements for Reviews and Ratings. When in doubt, discuss Rating and Review content with your CSM.


Google has its own content requirements for Reviews and Ratings. Always check their documentation page for the most up to date content requirements.  When in doubt, discuss Rating and Review content with your CSM.


FAQPage

Content & Code Requirement

Ensure all FAQs follow a standardized HTML format & structure (e.g questions are always an <h3> element with a nested <p>). If the answer element is a sibling to the question element, ideally it should contain the entirety of the answer text (e.g <div id = faq-answer> with nested elements.


If FAQs are written in an accordion, ideally that accordion should be differentiated from other accordions (e.g <div id = “faq_accordion”>). Ensure all content is accessible to the Highlighter & present on the same URL (e.g avoid Answers contained in Javascript generated pop-up windows). 


Omni Linked Entity Recognition

Content & Code Requirements

An Omni Linked Entity Recognition highlight works best when we can target one single HTML component that contains all our desired content. For example, we may want to target all of an article’s written content, but not the footer and recommended articles immediately below the article. 


Targets our desired HTML component

Ineffective Targeting (Too broad)

<div id = “article-body>

    <p> article text </>

<div/>

<div id = article-footer”>

    <a>text link</a>

</div>

<div id = “whole-article-content-page”>

<p> article text </p>

<p> article text </p>

<div> id = “footer-summary”> </div>

<p> id = author-bio </p>

</div>



Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons

Feedback sent

We appreciate your effort and will try to fix the article