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
cleanup Physician per #806 to clarify that a physician is not a place, adding /usNPI identifiers #3420
Comments
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 |
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:
plus
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. |
Maybe a crazy thought but might not It's something a bunch of us discussed years back for the health-lifesci extension. Only back than we came up with a new
In which case we can express things like:
And if we were to take it one step further and have
We could express things like:
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. |
Oh, and as for animals, isn't it about time 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
|
I am happy to see that the chickens have come home to roost about the NPI numbers: Two types (Individual Person, Organization)CMS assigns two types of NPI Numbers: #806 (comment)
In order to assign the NPI numbers properly, we must disambiguate the Physician person from the Physician organization:
Summary of issuesIn 2016 I wrote about the many issues we would face by leaving the
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 |
see #3427 (comment) for a concrete proposal |
in #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. |
I think that would work although having gone through all the (past) issues and initiatives surrounding this topic, made me wonder a few things:
|
Thanks for investigating!
@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). |
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. |
OK the PR is merged. Thanks, everyone! |
Just to continue an X conversation here... @danbri wrote: The class tree would than be: Which I agree with bu-ut... Might it be an idea to also expand the domain of Reason being that it's quite cumbersome to have to create multi typed entities to be able to express the This change would reflect the same sort of sub typing as |
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 Note this isn't my favorite option either, but I wouldn't have made the first change like Dan did. |
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 |
I just realized that the domain of Could we please also make that change? |
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:
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:
3.) add /usNPI, a /Property whose value is /Text (using /Number doesn't add much here); domainIncludes /Physician.
4.) Add /practicesAt, a /Property whose value is a /MedicalOrganization; domainIncludes /Physician.
Definition:
The text was updated successfully, but these errors were encountered: