Medical/health vocabulary as an extension

[unor]

Would it be possible to remove the health/medical types from the main namespace and make it an extension, e.g. http://med.schema.org/?

As the Extension Mechanism documentation explains,

Schema.org provides a core, basic vocabulary for describing the kind of entities the most common web applications need.

But MedicalEntity is rather domain specific, not something "the most common" sites would use.

[danbri]

Yes, we have not discussed this with @twamarc (who led an existing proposal #11 ) but given the scale and detail of our medical vocabulary this is indeed a strong candidate for conversion into a med: extension. Probably it is best to test the infrastructure with something smaller first (bib: and auto:), but thanks for starting this conversation. @twamarc - have you followed any of the discussion around the new extension model? http://schema.org/docs/extension.html has an overview...

[twamarc]

I personally support this approach as a way forward (but I have not yet discussed with the group which was behind the proposal last year).
We-all of us I guess, followed with interest the recent discussions about schema extension mechanism and how things keep evolving at schema.org. I am still convinced that the medical vocabulary existing in schema.org should be improved and making it an extension, maintained by some people would help to make it robust and up-to-date.
Just looking at the proposal, some of suggested concepts have been already integrated in schema---there is a need to align the proposal to the existing schema version (eliminating duplicates, etc)

In parallel there is (since end last year) a big move towards having robust medical vocabulary and within the W3C Life science Group with the start of the HL7 ITS subgroup on RDF for Semantic Interoperability. The group is nowadays working among others on HL7 FHIR Ontology which may help/overlaps with the proposal.
Sure the group will not back the proposal but the existing of the extension will be an added value.

The 2 questions I have here (for next steps):
-should we still use the same namespace schema: or we will use something else depending to the extension, eg. med.schema: ?
-Is there a mechanism (a developer's site ) to maintain the proposal or we need to that in an external API?

[danbri]

@twamarc thanks for your reply, and your patience.

To answer your specific questions:

1.) Each hosted extension (http://schema.org/docs/extension.html) will be assigned a short code name. This is used as a folder name in the codebase (e.g. data/ext/bib/* for bibliographic), and when publiched as a subdomain in the site (i.e. we will eventually have bib.schema.org). Q: would 'med' be an adequate short name for the vocabulary we discuss here? (rather than something alluding to 'healthcare', 'life science' etc.?).

However, do note that unlike "classic RDF Linked Data" the names assigned within the extension should be designed to be used alongside all other terms (from the core and even from other extensions). This means that we still need some central coordination, and that names of type/property/enum terms should be specific. For example, we made a previously by using "/action" to mean "muscle action", and we will need to create a workflow based around the new W3C Community Group and Github to help improve our naming choices. This new extension mechanism was only announced fully last week with the v2.0 release, and there are still some tooling and workflow issues to finalize.

2.) ... consequently there is not yet full documentation for developers of extensions, beyond the high level notes in http://schema.org/docs/extension.html

For now, everything is in Github. We do have a special label here (for issues and pull requests) regarding extensions.

For a path forward for Medical/Health I suggest,

• confirm whether we think 'med' is a reasonable short name for the scope of this work.
• Let's prepare here a 3-4 sentence overview of the extension. We should say how it interacts with the core. I've made a rough draft below as a conversation starter only, including a sketch of the kind of workflow template we'll need to standardize as we improve the Extensions documentation.
• Technical work of revisiting the draft in First draft of medicalEntity extension proposal  #11 and re-structuring it as 1. changes to data/schema.rdfa 2. an extension in data/ext/med/medvocab.rdfa 3. update examples accordingly.

For example would this be a fair initial template description?:

"""The medical extension refines and improves schema.org's medical/healthcare vocabulary that was initially published in 2012 (see http://blog.schema.org/2012/06/health-and-medical-vocabulary-for.html http://schema.org/docs/meddocs.html ). Taking into various integration points post-2012 changes (e.g. Audience, action / muscleAction), it moves schema.org's detailed treatment of medical terminology into a extension called 'med'.

• The following terms are moved (todo: list).
• The following terms are renamed (todo: list) with the core.
• The following terms are renamed (todo: list) and moved into the extension.
• The following terms are created (todo: list) within the core.
• The following terms are created (todo: list) within the extension.
• The following somewhat medically-related terms remain in the core (todo: list, e.g. http://schema.org/Recipe).
• The following extension-related discussions are noted as relevant (todo: list, e.g. GS1, nutrition/food, ...).
• The following related standards groups have been identified and invited to comment. (todo: list).
• [ ](meta: did I miss any obvious workflow questions --@danbri?) """

[twamarc]

Hi Colleagues,
Hi Dan Brickley,

Here are some preliminary informations to start the health.schema.org Extension.

1. The name: #health.schema.org (See votes communicated earlier)
2. The short overview of the extension: See Preparing a 3-4 sentence overview of the health.schema.org extension twamarc/ScheMed#1)
   "
   The medical extension refines and improves schema.org's medical/healthcare vocabulary that was initially published in 2012 (see http://blog.schema.org/2012/06/health-and-medical-vocabulary-for.htmlhttp://schema.org/docs/meddocs.html ).
   Taking into various integration points post-2012 changes (e.g. Audience, action / muscleAction, Enumeration), and with community effort to extend and polish existing version (e.g adding other concepts like the Medical Encounter, Medical Procedure, Health, Health Insurance, Genetics ) , it moves the existing schema.org's medical vocabulary into a dedicated extension called 'health.schema.org.
   "
   3)Technical work of revisiting the draft in First draft of medicalEntity extension proposal  #11 and re-structuring: ONGOING

PLANNED:
4) The list of terms that are moved (todo: list).
5) The list of terms that are renamed (todo: list) with the core.
6) The list of terms that are renamed (todo: list) and moved into the extension.
7) The list of terms that are created (todo: list) within the core.
8) The list of terms that are created (todo: list) within the extension.
9) The list of terms that are somewhat medically-related terms but remain in the core (todo: list, e.g. http://schema.org/Recipe).
10)The list of extension-related discussions that are noted as relevant (todo: list, e.g. GS1, nutrition/food, ...).
11) The list of terms that are related standards groups that have been identified and invited to comment. (todo: list).

12)Coordinate with Food type (help further with foodWarning and recipeIngredient) #458

Regards,
Marc

[danbri]

Thanks. I'll put this on Steering Group's next agenda, likely we'll have a call in ~ 2 weeks.

[twamarc]

Great!
Let me know (some day before)if I have to invite available participants from https://www.w3.org/community/schemed/ so I can set up a TCon bridge.

[danbri]

@twamarc - could you add links to the latest discussions, drafts, meeting notes etc into this issue? I'd like #492 to be a general "one stop shop" for schema.org community members to check into the status of this work.

[twamarc]

Sure, I will populate all related discussions from other issues

[danbri]

Thanks, that would be really useful!

[twamarc]

Current ongoing work:
-(Step one-)The minimum requirement for first version of health.schema.org extension (#11), based upon those terms identified in the current core of schema.org as candidates for moving into a health extension:
*see @RichardWallis: twamarc/ScheMed#11 (comment)
*see @danbri : twamarc/ScheMed#11 (comment)
also in line with last ScheMed CG meeting discussions:
*Quoting @rvguha experience (http://www.w3.org/2015/08/28-schemed-minutes.html)

-(Step one-bis)Working on the partial notes about the exact choice of name for each term inhealth.schema.org extension @danbri in #2
*see: twamarc/ScheMed#2 (comment); from what a couple of issues have been opened :
#twamarc/ScheMed#20 |Terms/words choice or re-use in health extension: action, activityDuration, etc
#twamarc/ScheMed#19 |Terms/words choice: re-work on too broad or vague terms like Vessel, Appearance, Balance, CT, Completed, Emergency, etc.
#twamarc/ScheMed#18 |Removing the medical sense of 'action' (deprecate).
#twamarc/ScheMed#17 |Recipe and existing Recipe vocab to stay in core?
#twamarc/ScheMed#16 |Move from core to extension: MedicalAudience
#twamarc/ScheMed#15 |Move from core to extension: Diet, DietarySupplement
#twamarc/ScheMed#14 |Move from core to extension: consider if we move Place / LocalBusiness -related types

-(Step two-): Additions, enhancement, wide community review including:
--Under investigation: support nutrition vocab and see convergence with GS1:
see also
#twamarc/ScheMed#13 |Optimizing health extension for nutrition vocabs Enhancement (cc/ @mgh128)

--Under investigation: support clinical trials data/vocab (cc/ @micheldumontier)
see also
#twamarc/ScheMed#12 |Optimizing health extension for clinical trials data/vocab Enhancement

--Under investigation: support for genetics and pharmacogenetics vocab (@markwoon)
see also
#twamarc/ScheMed#6 | Support for genetics and pharmacogenetics

--Under investigation: support for Health Insurance markup #twamarc/ScheMed#3 (cc/ @ccorak, @DavidXPortnoy)

That's for now.
~Marc

[twamarc]

Added:
-ScheMed CG wiki page: https://www.w3.org/community/schemed/wiki/Main_Page
-Meetings:
*Last meeting minutes: http://www.w3.org/2015/08/28-schemed-minutes.html
*Coming meeting 25 September (4.00pm UK Time(11.00am Boston Time | 3.00pm GMT):)

[twamarc]

@RichardWallis
I have just committed the extraction of all medical vocabs from the schema core to health extension v0.2. I left in core some vocabs to be discussed (nutrition, Recipe and physicalActivity | Fitness) this will be discussed in coming SchemED CG meetings.

I merged with sdo-phobos, and passed all tests successfully. However it seems there I miss something: the test are OK and I see that some orphan domain|range terms are not detected by the tests.

eg. See the http://schema.org/indication :

health:indication Domain: health:CaringEvent Domain: health:MedicalDevice Domain: health:MedicalIntervention Domain: health:MedicalProcedure Domain: health:TherapeuticProcedure Range: health:MedicalIndication

here: the 3 listed domains are not defined in core neither in the extension (accidentally there as a legacy of v0.1 health.schema.org):

health:MedicalIntervention
health:CaringEvent
health:MedicalIndication

So I was expecting the tests to detect them and I can correct this immediately. Unfortunately not.
Of course I can do that manually-- time consuming.

Can you pass the stets at your side?
https://github.com/twamarc/schemaorg/blob/master/data/ext/health/health_core-0.2.rdfa
https://github.com/twamarc/schemaorg/blob/master/data/schema.rdfa

Following our disussions I guess this will be published under
http://health.sdo-schemedex.appspot.com/MedicalEntity
Then we will work deeply on this first draft of this extract proposal through those individual terms identifying issues and comments, to get it ready for proposal.
Am still working on them, examples and rationale text.
Thanks,

~Marc

[RichardWallis]

@twamarc I get the following failures when I run the tests:

FAIL: test_validDomainIncludes (test_graphs.SDOGraphSetupTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/wallisr/Development/schemaorg/health 0.2/schemaorg/tests/test_graphs.py", line 164, in test_validDomainIncludes
    self.assertEqual(len(nri1_results), 0, "DomainIncludes should define valid type. Found: %s" % len(nri1_results))
AssertionError: DomainIncludes should define valid type. Found: 11

======================================================================
FAIL: test_validRangeIncludes (test_graphs.SDOGraphSetupTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/wallisr/Development/schemaorg/health 0.2/schemaorg/tests/test_graphs.py", line 148, in test_validRangeIncludes
    self.assertEqual(len(nri1_results), 0, "RangeIncludes should define valid type. Found: %s" % len(nri1_results))
AssertionError: RangeIncludes should define valid type. Found: 4

Scrolling back up the test output you will see informational reports for the 11 offending domainIncludes and 4 rangeIncludes.

[twamarc]

@RichardWallis
I still failed to run the following tests : tests/test_basics.py AND tests_graphs.py
I have thefollowing returned error:

$ python tests/test_basics.py
Traceback (most recent call last):
File "tests/test_basics.py", line 8, in
from sdoapp import *
File "d:\Users\axpzc\schemaorg\sdoapp.py", line 6, in
import webapp2
ImportError: No module named webapp2

The tests under scripts/run_tests.py are OK at my side:
Ran 61 tests in 15.268s
OK (skipped=1)

So I tried to fix the domainIncludes and rangeIncludes issues manually (not sure I fixed them all): can you run the tests at your side again?

Thanks

[RichardWallis]

@twamarc check for the following in your environment: PYTHONPATH=/usr/local/google_appengine
That should fix your problem. Yell if not.

Meanwhile here are the error reports I'm getting:

test_validDomainIncludes (test_graphs.SDOGraphSetupTestCase) ... INFO:test_graphs:Property http://schema.org/biomechnicalClass invalid domainIncludes value: http://schema.org/Joint

INFO:test_graphs:Property http://schema.org/frequency invalid domainIncludes value: http://schema.org/DoseSchedule

INFO:test_graphs:Property http://schema.org/hospitalAffiliation invalid domainIncludes value: http://schema.org/Physician

INFO:test_graphs:Property http://schema.org/proprietaryName invalid domainIncludes value: http://schema.org/Diet

INFO:test_graphs:Property http://schema.org/purpose invalid domainIncludes value: http://schema.org/MedicalDevice

INFO:test_graphs:Property http://schema.org/sourcedFrom invalid domainIncludes value: http://schema.org/Nerve

INFO:test_graphs:Property http://schema.org/tissueSample invalid domainIncludes value: http://schema.org/PathologyTest

INFO:test_graphs:Property http://schema.org/totalTime invalid domainIncludes value: http://schema.org/MedicalProcedure

FAIL
test_validRangeIncludes (test_graphs.SDOGraphSetupTestCase) ... INFO:test_graphs:Property http://schema.org/hospitalAffiliation invalid rangeIncludes value: http://schema.org/Hospital

INFO:test_graphs:Property http://schema.org/purpose invalid rangeIncludes value: http://schema.org/MedicalDevicePurpose

INFO:test_graphs:Property http://schema.org/sourcedFrom invalid rangeIncludes value: http://schema.org/BrainStructure

FAIL

[twamarc]

@RichardWallis Thanks. Not solved at my side (I guess windows config problem?).
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\rdflib\plugins\parsers\pyRdfa__init__.py", line 580, in graph_from_source
if not rdfOutput : raise f
rdflib.plugins.parsers.pyRdfa.FailedSource
ERROR

However I fixed the above errors--still manually. Can you test again? :)

[twamarc]

Hmmm! this is an interesting discussion but please let's keep this simple.
I would suggest to make a complete proposal on the spreadsheet shared by @LeezaRodriguez 👍

https://docs.google.com/spreadsheets/d/1y7KIP0icoqowZ1uX4H33rVJKfj5WAjIeqkEpnuN6A9U/edit#gid=0
So in the next improvement we will propose all the Medical Specialty adjective descriptions into nouns.
The individuals with such specialities will be enumerated under the HealthcareProvider types.

Most usecases we can use the following example model:

Physician
   >medicalSpeciality
        > (one of enumerated values of MedicalSpeciality : RE-FACTORED see the spreadsheet )
        >medicalDegree (TO BE CREATED)
            >(one of enumerated values of MedicalDegree : TO BE CREATED )   
        >certifyingBoard (TO BE CREATED)
            >(one of enumerated values of MedicalCertifyingBoard: TO BE CREATED )           

In this way we will cover both US and EU (taking example of Belgian model and EU commission) use cases.
Can we agree on this as a conclusion to this @westurner and @LeezaRodriguez ?
This will close the issue twamarc/ScheMed#34 as well.

Thanks for rich input on this!
Marc

cc/ @danbri , @davefeg , @vholland , @RichardWallis

[westurner]

re: Thing > Intangible > Credential > Degree > MedicalDegree

In order that we all might have equal rights,

From twamarc/ScheMed#34 (comment) [edit]:

from the Schema.org Course Extension "schema document":

Thing > Intangible > Credential > OpenBadgesBadgeClass
An OpenBadges BadgeClass.

• RDF integration: schema.org/Certification and schema.org/BadgeCriteria 1EdTech/openbadges-specification#9
• https://twitter.com/philbarker/status/689815591318863872

Thing > Intangible > Credential > Badge > OpenBadgesBadge

• JWS signatures and JSON-LD
  • see: http://json-ld.org/playground/ > “Event” > “Signed” tab pane (#pane-signed)
• JWS signatures and RDFa

[LeezaRodriguez]

@twamarc Sounds great to me!

For Physician we could also have properties to identify medicineSystem and the recognizingAuthority of the Medical Board. This would allow search engines to better distinguish between doctors practicing traditional western medicine vs. osteopathic medicine. Consumers without a medical background might not even realize that a healthcare provider whose name is preceded by 'Dr.' can be a Medical Doctor (M.D), or an Osteopath (D.O). And there is big difference in how each doctor would approach the delivery of a baby ....

Joe Smith, M.D., an OB/GYN practicing western medicine

• medicalDegree = Medical Doctor (M.D.)
• medicineSystem=Western Conventional
• medicalSpecialty= Obstetrics and Gynecology
• certifyingBoard=American Board of Obstetrics and Gynecology
• recognizingAuthority=American Board of Medical Specialties (ABMS)

Mary Grace, D.O., OB/GYN practicing osteopathic medicine

• medicalDegree= Doctor of Osteopath (D.O.)
• medicineSystem=Osteopathic
• medicalSpecialty=Obstetrics and Gynecology
• certifyingBoard=American Osteopathic Board of Obstetrics and Gynecology
• recognizingAuthority=American Osteopathic Association

[westurner]

Is it possible to have multiple degrees?

[LeezaRodriguez]

@westurner Yes, it is possible for a physician to have multiple degrees. In the US, there are some physicians who complete dental school (DDS ), and then apply to medical school to attain the MD degree. However, it is highly unusual to see an MD/OD combination.

What is more common in Medicine is to see MDs with Board Certification in two or more Medical Subspecialties or Medical Specialties. Each Board Certification means that they have completed a Residency in that Medical Specialty and successfully completed the examination requirements. However, these double boarded physicians will typically claim a primary Medical Specialty, and focus their medical practice on only one. Malpractice policies and hospital credentialing (admitting privileges) will typically require the physician to specify which is the primary Medical Specialty.

[LeezaRodriguez]

@westurner : I see your recent post (#195) from today defining Credential. Which of these would be applicable to a Medical Specialty or Subspecialty certificate awarded to a M.D. or D.O. upon completion of a medical residency? For the record these credentials are not 'medical licenses', as 'licenses' are issued by individual State and Government jurisdictions. It would be great to make 'MedicalResidency' credential crystal clear for webmasters of medical teaching institutions/medical portals. Thx.

[westurner]

@LeezaRodriguez

• Is it a Certificate or a Certification?
  • Certifications imply re-certification (and validFrom, validUntil, etc.)
• This assumes fiat (that Credential, CredentialInstance, and DegreeType as in Course, CourseInstance, EducationEvent [Schema.org Course Extension] #195 Schema.org Course Extension RDFa & Examples #972 will be merged and then exist in schema.org core).
  • I just wrote this up today. I'm still working on examples. Thanks for reminding me of this use case.

Schema RDFa:

<div typeof="rdfs:Class" resource="http://schema.org/MedicalSpecialtyCertificate">
    <span class="h" property="rdfs:label">MedicalSpecialtyCertificate</span>
    <span property="rdfs:comment">A MedicalSpecialtyCertificate Credential TODO</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Certificate">Certificate</a></span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/CertificateType">CertificateType</a></span>
    <!-- TODO: OR -->
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Certification">Certification</a></span>
</div>

<div typeof="rdf:Property" resource="http://schema.org/medicalDegree">
  <span class="h" property="rdfs:label">medicalDegree</span>
  <span property="rdfs:comment">A MedicalDegree for this Person</span>
  <link property="rdfs:subPropertyOf" href="http://schema.org/credential" />
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/Person">Person</a></span>
  <!-- TODO: see 'is a physician a person' -->
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/Person">Physician</a></span>
  <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/MedicalDegree">MedicalDegree</a></span>
</div>

<div typeof="rdf:Property" resource="http://schema.org/certifyingBoard">
  <span class="h" property="rdfs:label">certifyingBoard</span>
  <span property="rdfs:comment">TODO</span>
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/MedicalSpecialtyCertificate">MedicalSpecialtyCertificate</a></span>
  <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Organization">Organization</a></span>
  <!-- this is not yet solved for: -->
  <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/CredentialInstance">CredentialInstance</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/MedicalDegreeType">
    <span class="h" property="rdfs:label">MedicalDegreeType</span>
    <span property="rdfs:comment">A type of an Medical Degree AcademicDegree</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/AcademicDegreeType">AcademicDegreeType</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/MedicalDoctorDegree">
    <span class="h" property="rdfs:label">MedicalDoctorDegree</span>
    <span property="rdfs:comment">A MedicalDoctor Degree MedicalDegreeType</span>
    <span property="schema:alternateName">MD</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalDegreeType">MedicalDegreeType</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/OsteopathicDoctorDegree">
    <span class="h" property="rdfs:label">OsteopathicDoctorDegree</span>
    <span property="rdfs:comment">A OsteopathicDoctor Degree MedicalDegreeType</span>
    <span property="schema:alternateName">DO</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalDegreeType">MedicalDegreeType</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/PodiatricDoctorDegree">
    <span class="h" property="rdfs:label">PodiatricDoctorDegree</span>
    <span property="rdfs:comment">A PodiatricDoctor Degree MedicalDegreeType</span>
    <span property="schema:alternateName">DPM</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalDegreeType">MedicalDegreeType</a></span>
</div>


<div typeof="rdf:Property" resource="http://schema.org/abbreviation">
  <span class="h" property="rdfs:label">abbreviation</span>
  <span property="rdfs:comment">An abbreviation (see also: alternateName)</span>
  <span>Thing: <a property="http://schema.org/domainIncludes" href="http://schema.org/Thing">Thing</a></span>
  <span>Text: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Text">Text</a></span>
  <span>Abbreviation: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Abbreviation">Abbreviation</a></span>
</div>

<div typeof="rdfs:Class" resource="http://schema.org/Abbreviation">
    <span class="h" property="rdfs:label">Abbreviation</span>
    <span property="rdfs:comment">An abbreviation for something (name for abbreviation, description for a description of context)</span>
    <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Intangible">Intangible</a></span>
</div>

JSON-LD example:

TYPES: #MedicalSpecialtyCertificate1 CredentialInstance, MedicalSpecialtyCertificate

"@type": "CredentialInstance",
  "credentialIssuee": {
    "@type": "Person",
    "name": "Joe Smith, M.D."
  },
  "credential": {
    "@type": "MedicalSpecialtyCertificate",
    "credentialType": "MedicalSpecialtyCertificate",
    "credentialIssuer": {
      "@type": "Organization",
      "name": "American Board of Obstetrics and Gynecology",
      "url": "..."
    },
    "medicalDegree": {
      "@type": "MedicalDegree",
      "credentialType": "MedicalDoctorDegree"
    },
    "medicineSystem": "WesternConventional",
    "medicalSpecialty": ["Obstetric", "Gynecologic"],
    "certifyingBoard": {
      "@type": "Organization",
      "name": "American Board of Obstetrics and Gynecology",
      "url": "..."
    },
    "recognizingAuthority": {
      "@type": "Organization",
      "name": "American Board of Medical Specialties (ABMS)",
      "url": "..."
    }
)

• [-] medicalDegree
• [-] MedicalDegree (see below)
• https://health-lifesci.schema.org/medicineSystem
• https://health-lifesci.schema.org/MedicineSystem
• https://health-lifesci.schema.org/medicalSpecialty
• https://health-lifesci.schema.org/MedicalSpecialty
• [-] https://health-lifesci.schema.org/certifyingBoard
• https://health-lifesci.schema.org/recognizingAuthority

MedicalDegreeType

Regarding degrees:

• Thing > CreativeWork > Credential > AcademicDegree > DoctoralDegree
• [-] Thing > CreativeWork > Credential > AcademicDegree > MedicalDegree
• [-] CredentialType > AcademicDegreeType > MedicalDegreeType
  • [-] MedicalDegreeType > MedicalDoctorDegree (MD)
  • [-] MedicalDegreeType > OsteopathicDoctorDegree (DO)
  • [-] MedicalDegreeType > PodiatricDoctorDegree (DPM)
  • MedicalDegree > NursingDegree
  • MedicalDegreeType > NursingDegreeType
    • Types are combinable (BachelorDegree, NursingDegreeType})
    • NursingDegreeType >
      • {BachelorDegree, NursingDegree} > BSN
      • {GraduateDegree, NursingDegree} > MSN
      • {DoctorateDegree, NursingDegree} > ND
      • LPN
      • LSN

is a Physician a Person?

Regarding http://schema.org/Physician :

• Thing > Organization > MedicalOrganization > Physician
• Thing > Person > Physician

how to specify a primary MedicalSpecialtyCertificate

I can think of twoo ways to do primaryMedicalSpecialtyCertificate:

• subclass CredentialInstance and create a property
  • CredentialInstance > MedicalSpecialtyCertificateInstance
    • P: primaryMedicalSpecialtyCertificate d: Person r: MedicalSpecialtyCertificateInstance
      • d: Physician ? (Organization / Person)
• create isPrimaryCredential and then
  isPrimaryMedicalSpecialtyCertificate as a subPropertyOf
  • P: CredentialInstance.isPrimaryCredential
    • P: CredentialInstance.isPrimaryMedicalSpecialtyCertificate r: MedicalSpecialtyCertificateInstance

And then there's trying to rely on the source order
so that the first listed is assumed the primary MedicalSpecialtyCertificate;
which works differently in different representations:

• RDFa, Microdata: most parsers preserve source order
• JSON-LD: the parser may preserve source order, JSON libraries may not preserve source order (of hash maps)

[danbri]

"And then there's trying to rely on the source order" - for schema.org we need the order to be explicit; it is not enough to rely on the order that information is found within a document being parsed.

[LeezaRodriguez]

@westurner I love the way you are thinking, especially associating the Medical Specialty certificates (ex: Obstetrics) with their certifyingBoard (American Board of Obstetrics and Gynecology) with oversight by a recognizingAuthority (American Board of Medical Specialties). YES! These relationships are critical for search engines to eventually figure out who the bogus Medical Boards are. Bogus Boards have little or no oversight (no recognizingAuthority).

To answer your questions:

Medical Residency certificate or certification?
Based on your description, in the USA, the Medical Specialty completion is a certification. Most certificates have 'issued' and 'valid until' fields. However, some Medical Specialties still have a grandfather clause such that 'valid until= indefinitely' appears on the certificate.

Is Schema.org/Physician a person?
No, it currently represents a doctor's office, a place. I believe this is confusing for webmasters and will create problems. @twamarc has assured me that this issue will be addressed in the next version. Personally, I don't think we should wait to do this. Why the rush? Not to sound too dramatic, but I think we are already facing an ontology alignment issue. Allow me:

• In Freebase, Physician MID was typed as a person
• In Wikidata, Physician QID is a person, and the associated MID from Freebase is already listed as a property on this item.

And to make it more interesting, the Google KG shows Physician as a 'profession'.

What to do?
We need to disambiguate between the Physician office and the Physician person. If we don't, this could become very messy with respect to Board Certification, licenses, insurance and Clinical Trial vocabulary . In the USA, the physician person and the physician office are two completely different entities. Each entity has it's own NPI (National Provider Identifier) number. Furthermore, Board Certifications and licenses to practice medicine are attached to the physician person, and not the organization entity. Just off the top of my head, here are some differences in the US:

Physician person gets these:

• Medical Specialty Certification (from an academic institution upon completion of a residency)
• Board Certification (from a Medical Board after taking exams following residency completion)
• State License to practice medicine (from the State Government)
• DEA number (from the US Gov to write prescriptions)
• NPI number (from HHS Fed Gov)
• Malpractice policy (commercial entity)
• Tax ID number (Fed Gov)
• Primary Investigator in a Clinical Trial (FDA)

Physician organization entity gets these:

• NPI number (from HHS Fed Gov)
• Tax ID number (Fed Gov)
• Clinical Trial Site or Sponsor (FDA)

But there's more...
In the next version, we need to modify the Medical Specialty enumerations to all be nouns (not adjectives), as well as modify the existing list to be more aligned with ABMS and the Worldwide Medical Specialities listed in Wikipedia. At the moment, IMO, it's a bit of a hot mess!

[westurner]

• These codes are different in different countries.
• Q: What would be the best way to model these country-specific Physician codes?
  • A. {Physician + PhysicianUnitedStates}, {Physician + PhysicianUnitedKingdom}
  • A. health-lifesci defines http://schema.org/code w/ range: http://schema.org/MedicalCode
    • MedicalCode then has:
    • codeValue
    • codingSystem
  • A. Is there another way? (Q)

[LeezaRodriguez]

@westurner Can you please clarify which codes you are referring to?

[westurner]

@LeezaRodriguez Physician license and certification numbers could be modeled as http://schema.org/Number codeValues, or -- more completely -- with classes and properties for each Credential.

With something like PhysicianUnitedStates, there could be defined properties for each requisite Credential.

With something like http://schema.org/MedicalCode codeValue codingSystem, there wouldn't be need to define each country's specific coding systems in health-lifesci; but that would be lossy

[LeezaRodriguez]

Thanks, and I agree http://schema.org/MedicalCode coding system does not need to be country specific.

But to digress a bit, I'm still not clear how the existing Physician organization type (http://schema.org/Physician) and the new Physician person type will be disambiguated in this schema.org hierarchy. ? Can you or @twamarc clarify for me?

• Does http://schema.org/Physician remain as an organization/local business in the core?
• Will a new ~ @PhysicianMD (person) type be designated in the extension or in the core?

WRT the physician person credentials , one could think of a medical 'license' to practice medicine in a particular state/jurisdiction/country as a 'permit' or a 'license'. However, the 'certification' in a MedicalSpecialty (following completion of a residency program) is absolutely it's own animal, not a 'degree', and is worthy of it's own property similar to what you outlined above.

[twamarc]

within the current fixes, the existing Physician organization (http://schema.org/Physician) and the new Physician person will be 2 different types.
i.e http://schema.org/Physician will remain as an organization/local business and remain in the core (probably definition fine-tuned -or used as PhysicianOffice) and the Physician person will be in the extension.

[danbri]

Just to clarify, it is a flat namespace: you can't have the same term in an extension and the core. So if the extension has a different notion of Physician-as-a-Person it can't be called 'Physician' if that term is used differently in the core.

[westurner]

In this instance, is there a reason that a Physician could not be both a
Person and an Organization?

Organization > Physician
Person > Physician

Organization > MedicalTeam might've been a more specific relation than
Organization > Physician. AFAIU, schema migrations are relatively
impractical?

https://en.wikipedia.org/wiki/Physician

• Physician
• Medical Doctor
• Physician and Surgeon
• Internist (-> MedicalSpecialty)
• Hospitalist (-> MedicalSpeciality)
• General Practitioner
• General Internist

On Jul 18, 2016 8:00 AM, "Dan Brickley" notifications@github.com wrote:

Just to clarify, it is a flat namespace: you can't have the same term in
an extension and the core. So if the extension has a different notion of
Physician-as-a-Person it can't be called 'Physician' if that term is used
differently in the core.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#492 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADGy2ONyDj5UGkJekrVusM_7CqkR9x5ks5qW2rMgaJpZM4EZ8rH
.

[thadguidry]

@LeezaRodriguez I have mentioned this before in your Freebase training days with me :) ... but to reiterate for all again... Schema.org (and in the past, Freebase) already has the 2 necessary types to disambiguate. There is no need to make a Physican#2 Type.

schema.org/Physician A PERSON (with a set of properties...to include all those you listed)
schema.org/MedicalOrganization A ORGANIZATION (with its own set of properties)

For us in Schema.org, both the Physician and the MedicalOrganization just need to have a few more properties defined under them, like npiID, (In fact, MedicalOrganization already has 4 useful ones like duns, leicode, vatID,, taxID) Reference: https://npiregistry.cms.hhs.gov/

The idea of our 2 existing Types already aligns perfectly with how Wikidata views things as well... internally Wikdata has Authority Control ID spaces for both our Types , Person and Organization !

https://www.wikidata.org/wiki/Q21745557 Wikidata property for authority control for organisations
https://www.wikidata.org/wiki/Q19595382 Wikidata property for authority control for people

So all that's needed is someone at or in Wikdata to make a proposal for a new property called NPI ID , such as all of these that exist already : SPARQL QUERY FOR UNIQUE IDS AND AUTHORITY CONTROL OF PEOPLE

[LeezaRodriguez]

Hi Thad! I'm still ever so grateful for my training wheels! Much insight , much joy.

To clarify the data modeling that Thad and I are describing:
A Physician is a person who is associated with or works for a MedicalOrganization. Webmasters need ability to model this relationship exactly and with ease.

A good path forward would be to immediately redefine http://schema.org/Physician to be a person. In this capacity, this Type would be properly aligned with other linked nodes in the ontology ecosystem, especially Wikidata, the new mothernode.

To overview the landscape, Physician is currently defined as such:

• Schema core: http://schema.org/Physician , 'a doctor’s office’ = A PLACE
• Wikidata: https://www.wikidata.org/wiki/Q39631 , “professional who practices medicine’ = A PERSON
• Freebase KG: https://g.co/kg/m/05t4q , ‘a professional who practices medicine’ = A PERSON ==> note that the Freebase MID is already designated as a property value within the Wikidata physician QID statements.

As you can see from the above, Physician is a person in Wikidata (and Freebase). The logical step forward is to make it a person in Schema.org. If not,.... who among you is fearless enough to go into Wikidata and make changes to the definitions there? If you try, you will never come out alive!!! .

Now, let's consider the relationship between the Physician (person) and the Organization he works for. I see redundancy with the types that are currently listed in the full hierarchy:

• http://schema.org/MedicalBusiness
• http://schema.org/MedicalOrganization

Perhaps we only need one of these types to show a relationship between the Physician and who he is affiliated with. MedicalOrganization is the most versatile, as it can be for profit or non-profit. Should we consider eliminating one of these?

Thoughts?

[thadguidry]

@LeezaRodriguez You forgot to mention the un-usefulness of bucket types (types without properties). :)

[LeezaRodriguez]

I realize this is painful, but we need to address the http://schema.org/Physician dilemma ASAP. There is already confusion in the wild. We can't take the easy way out. We have to think about how this will scale in the future!

As the schema.org vocab grows for the clinical trial space and the insurance industry this will likely get messy and come back to haunt, especially as Wikidata grows simultaneously . With insurance, not all doctors within a medical office or organization will participate with an insurance carrier.

If we don't model this to clearly show the relationship between the physician and the medical organization he works for/is affiliated with/is credentialed by, we are going to make it very difficult for search engines to understand the relationships.

How would we dare to not align http://schema.org/Physician with Wikidata QID 'Physician'? Please enlighten me.

Sorry to be such a nag :)

[ppKrauss]

Hi, I think is importante to notice and remember how ambiguous can be (some) SchemaOrg definitions, as "Physician", without a semantic link ... The issue#280 is to solve this problem with links to stable Wikidata concepts, but need help (!) and hands-on to evolve.

[LeezaRodriguez]

@ppKrauss Yes, and as you know @thadguidry is working on that mapping. Thad sees confusion with the current schema.org definition, and so do I.

This is why we are both suggesting to redefine http://schema.org/Physician as a person. Again, I realize this is a bit of a headache.

But otherwise, we have to align the current http://schema.org/Physician with the Wikidata concept to be equivalent with 'a physician's office' , rather than 'physician' (the person) QID in Wikidata, https://www.wikidata.org/wiki/Q39631

And if we leave the current schema.org definition as it is, what vocab do we use for physician-the-person in the extension? You really can't use 'medicaldoctor', as that implies an M.D. degree, and does not include D.O.s, who are also physicians. Using the term 'doctor', could open up confusion with phD's.

[danbri]

The health-lifesci.schema.org extension was published in 3.0 and announced (after we fixed some bugs!) with 3.1 yesterday, http://blog.schema.org/2016/08/schemaorg-update-hotels-datasets-health.html

There are various themes of discussion continuing here but all muddled together. I will close out this issue, and encourage all continued discussions to happen via more dedicated issues. Do create them if necessary but have a look for any pre-existing older issues first, we have 100s open and it's important to keep our open issue count under country.

Thanks again to everyone who contributed to the health-lifesci milestone - it was one of the largest structural changes we've made to how the schemas here are organized.

[jetaro1]

thanks all :)