cleanup Physician per #806 to clarify that a physician is not a place, adding /usNPI identifiers

[danbri]

We have a longstanding issue (partially cleaned in #806) due to the choice of naming for the type Physician, which represents "a doctor's office" and has a variety of supertypes:

• Thing > Organization > LocalBusiness > MedicalBusiness > Physician
• Thing > Place > LocalBusiness > MedicalBusiness > Physician
• Thing > Organization > MedicalOrganization > Physician

The current poor typing as a LocalBusiness (via MedicalBusiness) brings in the subtype of Place. In #806 we decoupled MedicalOrganization from this hierarchy (although note that such organizations can have an address). We should continue this cleanup by removing the assertion that a Physician is a MedicalBusiness, leaving it typed just as a MedicalOrganization. For association with places we can draw attention to the address and hospitalAffiliation properties, with potential to add /practicesAt for more specificity and to cover clinics etc.

Changes

1.) remove: Physician subClassOf LocalBusiness.

2.) Reword definition. Instead of "A physician's office", something like:

An individual physician, considered as a [[MedicalOrganization]]. For their official address use [[address], for affiliations to hospitals use [[hospitalAffiliation]]. The (todo) [[practicesAt]] property can be used to indicate [[MedicalOrganization]] hospitals, clinkics, pharmacies etc. where this physician practices. If there is a need to describe the physician as a [[Person]], the [[founder]] property can be used.

3.) add /usNPI, a /Property whose value is /Text (using /Number doesn't add much here); domainIncludes /Physician.

A US NPI (National Provider Number) is a unique 10-digit identification number issued to health care providers in the US.

4.) Add /practicesAt, a /Property whose value is a /MedicalOrganization; domainIncludes /Physician.

Definition:

Indicates a medical organization where this physician practices.

[danbri]

The context for this is a request from Data Commons, who are keen to publish (using Schema.org vocabulary and the DataCommons.org infrastructure) various NPI datasets being made available in the US; @hareesh-ms is taking a lead on this.

A related suggestion was to align more closely with FHIR and FHIR's notion of a Practitioner "A person who is directly or indirectly involved in the provisioning of healthcare or related services.", so we could have a broader structure analogous to our existing Patient class. Patient is currently a subtype of Person, however FHIR's Practitioner also covers service animals, and the documentation mentions "personal/animal". Although schema.org's Person type is defined as "A person (alive, dead, undead, or fictional).", it's not clear subtyping Person is the best plan here, so we'd need to figure out where to put Practitioner. Either way, some Physician cleanup seems useful. /cc @rvguha @shifucun

[danbri]

Practicalities. Some archaeology in support of changes (1.) and (2.) above:

we need to track down which data/*/ttl file (or files) contains the current definition of Physician.

It looks like we have assertions in two places:

find data/ext/ -name \*ttl -exec grep --with-filename Physician {} \; data/ext/health-lifesci/med-health-core.ttl::Physician a rdfs:Class ; data/ext/health-lifesci/med-health-core.ttl: :Physician ; data/ext/health-lifesci/med-health-core.ttl: :domainIncludes :Physician ; data/ext/health-lifesci/med-health-core.ttl: :Physician ;

plus

grep --with-filename Physician data/*ttl data/schema.ttl::Physician a rdfs:Class ; data/schema.ttl: rdfs:label "Physician" ;

Therefore to fix the definition text, we would change schema.ttl line 2275+. In addition the subtyping beneath MedicalBusiness occurs on lines 508-509 of med-health-core.ttl. Things are organized this way as a remnant of our largely failed attempt to modularize via named extensions / subdomains.

So (1.) is addressed by removing lines 508-509 of med-health-core.ttl, and (2.) by replacing the rdfs:comment in the main schema.ttl definition. As we're going to multi-line text this should probably be done with triple quotes in the .ttl syntax. For (3.) and (4.) let's just file additions in the data/ext/pending/*ttl tradition.

[jvandriel]

Maybe a crazy thought but might not Physician be better as a subtype of Occupation?

It's something a bunch of us discussed years back for the health-lifesci extension. Only back than we came up with a new Profession type (Google doc). Pretty much intended to be same class as Occupation, which didn't exist yet, and which included some additional subtypes as well (Nurse, Dentist, etc):

• Thing > Occupation > Physician

In which case we can express things like:

• Person > hasCredential > EducationalOccupationalCredential,
• Person > worksFor > MedicalOrganization,
• Person > hasOccupation > Physician,
• Physician > occupationalCategory > CategoryCode,
• Physician > occupationLocation > AdministrativeArea,
• Physician > qualifications > EducationalOccupationalCredential

And if we were to take it one step further and have Physician be a subtype of both Occupation and MedicalEntity:

• Thing > Occupation > Physician,
• Thing > MedicalEntity > Physician

We could express things like:

• Physician > relevantSpecialty (effectively swapping medicalSpecialty for relevantSpecialty),
• Physician > recognizingAuthority > Organization

More or less everything I can quickly come up with in regards to provenance and credentials. I know, there's a lot more to it but IMHO this a better alternative for the current situation and makes for a better starting point for changing it.

[jvandriel]

Oh, and as for animals, isn't it about time Animal was added to the vocabulary (and maybe also Plant)?

Even if they're just simple classes, with not that many properties, it would make things a lot easier just having those basic classes.

And if Patient becomes an Intangible we can simply write multi-typed entities and be done with it:

• "@type": ["Animal","Patient"],
• "@type": ["Person","Patient"],
• "@type": ["Plant","Patient"] (Yes, these also get sick)

[LeezaRodriguez]

I am happy to see that the chickens have come home to roost about the Physician Type . I admit it took longer than I thought. Before this gets cleaned up, this is what you need to know:

NPI numbers: Two types (Individual Person, Organization)

CMS assigns two types of NPI Numbers: https://github.com/schemaorg/schemaorg/issues/806#issuecomment-164163649

• Individual person (physician, person who practices medicine)
• Organization (medical practice, Facility, supplier, hospital, etc)

In order to assign the NPI numbers properly, we must disambiguate the Physician person from the Physician organization:

In the USA, the US government disambiguates between the physician person and the physician office. The physician person and the physician organization each apply for separate NPI numbers. You do not exist as an individual provider person or a medical organization if you do not have an NPI number. With insurance claims, carriers require the NPI numbers of both the individual physician and the physician organization. Also, an individual physician can practice medicine with several different physician organizations. Malpractice policies, claims, and associated data bank history are mainly associated with individual physicians. Individual physicians must have state licenses to practice medicine. Not all medical organizations will receive a state license , as often times the burden rests on the licenses of the individual physicians and their formal certification in a designated 'Medical Specialty'.

And with Clinical Trial registry, while the physician organization may be the trial sponsor or site, it is the individual physician who is the Primary Investigator.

Summary of issues

In 2016 I wrote about the many issues we would face by leaving the Physican type in it's current form. Please review: Physician person vs Physican organization: https://github.com/schemaorg/schemaorg/issues/280#issuecomment-253915688

Insurance Vocab: The Physician person and the Physician organization are separate entities and have different NPI numbers. Only some physicians in a Physician Organization may participate with an insurance carrier. We must be able to disambiguate the two.

Clinical Trial Vocab: In a Phase I, II, or III Clinical Trial, the Primary Investigator (PI) is a physician person, NOT the organization. But the Clinical Trial Location is typically the Physician organization, and not the person.

MedicalSpecialty: Technically speaking , a Medical Specialty has it's data provenance and lineage traced to the Physician person, and NOT the organization. It is the Physician who attains Board Certification by an authorized Medical Board in a given Medical Specialty. The organization simply inherits the Medical Speciality by virtue of the Physician person(s) who are employed by the organization. The organization can no longer claim a particular Medical Specialty if a physician person of that Medical Specialty leaves the organization. Bottom line, we need to show this foundational relationship of MedicalSpecialty with Physician person.

Hope this helps underscore that we can not merge the physican person and the physician organization into one entity. They are two. CMS disambiguates the difference, and so should we.

-Leeza

[danbri]

see https://github.com/schemaorg/schemaorg/pull/3427#issuecomment-1869470667 for a concrete proposal

[danbri]

in https://github.com/schemaorg/schemaorg/pull/3427 @jvandriel suggests making Physician a subtype of Occupation to benefit from https://schema.org/occupationalCategory. I am wary of the former as we could end up in a situation like Product where (amongst thousands of possibilities) only Vehicle is modeled as a subtype. However it is a great point that we ought to be able to use the occupationalCategory property, so I suggest we converge that suggestion into the "2 more precise subtypes" design proposed in the PR.

[jvandriel]

I think that would work although having gone through all the (past) issues and initiatives surrounding this topic, made me wonder a few things:

1. #806 also mentions Dentist (DentistOffice) and Optician (OpticianOffice), which makes me wonder whether these shouldn't be handled in a similar manner? (I have no idea whether dentists and opticians have US NPIs or not)
2. Would it be possible to provide some markup examples for the new classes? Reason I ask is because I expect many will want to publish information that will likely end up in folks having to use multi-typed entities ("@type":["IndividualPhysician","Person"] and/or "@type":["PhysiciansOffice","LocalBusiness"]) based on the type of information that can often be found on their respective webpages. A few examples that provide some guidance would for such situations would be much appreciated.

[danbri]

Thanks for investigating!

1. Ok, let's investigate Dentist and Optician but I would prefer to proceed with those as a followup activity rather than scope-creeping this issue. I'll open a ticket.
2. It would be possible, although markup examples can vary significantly depending on the target application. In this case @hareesh-ms & team are looking to import CSV-style data in the US into a large knowledge graph (data commons). It may be that a markup example could be created to capture that but it may correspond to search engine / web usecases (or the exact structures useful in other countries).

@hareesh-ms can you update your PR to add the occupationalCategory property to the Physician type (do it at that level and it will apply automatically to the new subtypes, i.e. add a domainIncludes triple from occupationalCategory to Physician). Also if you can suggest a markup example, just post it here and I can integrate it (or follow the format used in other data/ext/* files).

[jvandriel]

In regards to the markup examples, and just to be clear, I wasn't hinting at any full blown, all encompassing and SEO optimized markup examples.

I think it's fine to leave that up to any consuming party (like the search engines), but maybe we could at least provide some very basic examples illustrating the use of MTEs, as many still aren't aware we can make use of them. Yet for these particular classes it is to be expected people will make use of them.

Might as well point them the way by providing some simple hints.

[danbri]

OK the PR is merged. Thanks, everyone!

[jvandriel]

Just to continue an X conversation here... @danbri wrote: "@rrlevering suggests the PhysiciansOffice type could be a MedicalBusiness. I think this additional change makes sense."

The class tree would than be: Organization > LocalBusiness > MedicalBusiness > PhysiciansOffice Organization > MedicalOrganization > Physician > PhysiciansOffice

Which I agree with bu-ut...

Might it be an idea to also expand the domain of MedicalBusiness to MedicalOrganization as well?

Reason being that it's quite cumbersome to have to create multi typed entities to be able to express the medicalSpecialty of medical businesses or whether they accept new patients.

This change would reflect the same sort of sub typing as Organization > LocalBusiness though because MedicalOrganization and MedicalBusiness live in separate branches of the tree we now have to jump through hoops.

[rrlevering]

I don't think we were suggesting dropping the MedicalOrganization relationship (most of the predicates in Physician I think need to be inherited because Physician was more a business in schema.org than an individual so I think those things would need to be moved as well). So I'm suggesting:

Thing > Organization > MedicalOrganization > Physician > PhysiciansOffice Thing > Organization > LocalBusiness > MedicalBusiness > PhysiciansOffice Thing > Place > LocalBusiness > MedicalBusiness > PhysiciansOffice

Note this isn't my favorite option either, but I wouldn't have made the first change like Dan did.

[jvandriel]

I agree it's not the most gracious solution but anything else would probably have entailed a much larger overhaul. At least this has a strong use case, while also offering a solution for long standing issues surrounding Physician. We can always improve on that further down the road if needed.

[jvandriel]

I just realized that the domain of usNPI should probably be changed to MedicalBusiness because things like MedicalClinics have NPI numbers as well.

Could we please also make that change?

[github-actions[bot]]

This issue is being nudged due to inactivity.

[Kubot12]

NPI numbers: Two types (Individual Person, Organization)

I don't see any action for the comments of @LeezaRodriguez on making usNPI usable for organizations too.

As a use case, we have an NPI for each of our clinics. This is an organization NPI. The doctors may turnover and may have their own private practice NPI.

We need to be able to use usNPI under the organization, not only under physician.