Comments from Dan (#2):
I don't think Recipe should move to health from core - although there is clearly a connection

This is an internal place for Health-lifesci.schema.org Extension master plan and backlog.
We will assembly here all agreed on items, to be implemented in future. The purpose is not to lose track of item scattered in several issues comments.
All listed items should be linked to an opened issue at https://github.com/schemaorg/schemaorg/issues.

Release plans

• Health-lifesci.schema.org Extension v.1 published along the Schema.org 3.0
• Health-lifesci.schema.org Extension v.2 ready to be published: waiting the community interest to pick up the vocabulary
• Health-lifesci.schema.org Extension v.3 ready to be published: waiting the community interest to pick up the vocabulary

Issues backlog and planning

• schemaorg/schemaorg#1114 ==> [target: waiting for community interest]
• schemaorg/schemaorg#296 (comment) ==> [target: waiting for community interest]
• schemaorg/schemaorg#492 (comment) ==> [target: waiting for community interest]
• schemaorg/schemaorg#492 (comment) ==> [target: waiting for community interest]
• schemaorg/schemaorg#492 (comment) ==> [target: waiting for community interest]
• schemaorg/schemaorg#492 (comment) ==> [target: waiting for community interest]

Current version

    <div typeof="rdf:Property" resource="http://schema.org/diagnosis">
      <span class="h" property="rdfs:label">diagnosis</span>
      <span property="rdfs:comment">One or more alternative conditions considered in the differential diagnosis process.</span>
      <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/DDxElement">DDxElement</a></span>
      <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/MedicalCondition">MedicalCondition</a></span>
    </div>

Suggested

<div typeof="rdf:Property" resource="http://schema.org/diagnosis">
  <span class="h" property="rdfs:label"> health:diagnosis</span>
  <span property="rdfs:comment">One or more alternative conditions considered in the differential diagnosis process as output of a diagnosis process.</span>
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/DDxElement">health:DDxElement</a></span>
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/Patient"> health:Patient</a></span>
  <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/MedicalCondition"> health:MedicalCondition</a></span>
  <link property="http://schema.org/isPartOf" href="http://health.schema.org" />
</div>

Comments from Dan (#2)
We should consider if we move Place / LocalBusiness -related types: Dentist Hospital Optician Pharmacy Physician Clinician etc
(Dentistry vs Dentist?)
(some of these are also person-as-organization awkward)

MedicalAudience ... let's check that Audience navigation looks ok if we break out audiences this way; otherwise core should be fine. (See current proposal)

I suggest we expand the domain of medicalSpecialty to schema.org/MedicalOrganization.

Currently its domain is limited to schema.org/Hospital, schema.org/MedicalClinicand schema.org/Physician yet it would be very usefull to be able to specify it for other types of medical organizations as well (eg, a schema.org/DiagnosticLab that specializes in toxicology (relevantSpecialty > schema.org/Toxicologic), or a pediatric schema.org/Dentist (relevantSpecialty > schema.org/Pediatric)).

related to #14

Current version

:PsychologicalTreatment :subClassOf :MedicalTherapy

Suggested

:PsychologicalTreatment :subClassOf :TherapeuticProcedure

Rationale:
PsychologicalTreatment is broader than just a medical therapy and is is fitting well in TherapeuticProcedure hierarchy and not in MedicalTherapy.

I recommend that the first proposed release of heath.schema.org should be based upon those terms identified in the current core of schema.org as candidates for moving into a health extension.

The result of this being:

• to reduce the analysis work for a first proposal significantly
• to reduce the complexity of that analysis - at this stage it would be a question of move or not move
• to increase the likelihood of the extension proposal being accepted
• at this stage nothing would break

There may be a few other obvious changes that could be included, such as depreciating and replacing some conflicting property names. However anything more than that should be part of future proposals that can be created from clear use cases built upon this initial foundation.

Current version

:Patient :subClassOf :MedicalAudience

Suggested

:Patient :subClassOf :MedicalAudience
:Patient :subClassOf :Person

Rationale:
Obvious fix.

While we are preparing the health.schema.org extension, we need to agree on a short introduction for it. Dan proposed the following short text as starting point.

"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'. "

I need your feedback about it, any edition is higly welcome!

Comments from Dan (#2):
word choice - too broad or vague (cf. v2.0 cleanup)? e.g. words that have other senses. Expand or qualify acronyms?
e.g. Vessel, Appearance, Balance, CT, Completed, Emergency, Genetic, body parts (Ear, Head, ...?), MRI (e.g. MRIScan? MRIScanning?), Retail (rel. to ecommerce vocab?),
Suspended, Wholesale, ..., Withdrawn,
(noting that there is still a sense in which the namespace is flat; both in terms of term allocation, and eventual markup)

Current version

:PhysicalExam :subClassOf :MedicalEnumeration

Suggested

:PhysicalExam :subClassOf :MedicalProcedure

Rationale:
'PhysicalExam' is here defined as a procedure. So is fitting well in medical procedure hierarchy and not in enumeration.

Suggested also to extend its definition
Current version

    <div typeof="rdfs:Class" resource="http://schema.org/PhysicalExam">
      <span class="h" property="rdfs:label">PhysicalExam</span>
      <span property="rdfs:comment">A type of physical examination of a patient performed by a physician. Enumerated type.</span>
       <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalEnumeration">MedicalEnumeration</a></span>
       <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Enumeration">Enumeration</a></span>
       <span>Source:  <a property="dc:source" href="http://www.w3.org/wiki/WebSchemas/SchemaDotOrgSources#source_WikiDoc">WikiDoc</a></span>
    </div>

Suggested

<div typeof="rdfs:Class" resource="http://schema.org/PhysicalExam">
  <span class="h" property="rdfs:label"> health:PhysicalExam</span>
  <span property="rdfs:comment">A physical examination procedure of a patient performed by a healthcare provider: physician, nurse, etc. </span>
  <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalProcedure"> health:MedicalProcedure</a></span>
  <link property="http://schema.org/isPartOf" href="http://health.schema.org" />
</div>

Issue opened from @LeezaRodriguez comment on #33.

*Q / * Is it possible to clarify the definition of MedicalSpecialty so that is reflects the formal process of training, certification, and licensing?

Rationale : I'm afraid that webmasters may apply the term loosely, without knowledge that the designation of a 'MedicalSpecialty' is quite a formal thing. Any person or organization which is tied to a 'MedicalSpecialty' should have formal 'certification' and be 'licensed' in the Medical Specialty. The person or organization with a MedicalSpecialty must have attained training, certification, and licensing from an authority organization to practice medicine in that Medical Specialty.

When a physician asserts himself as a provider of care in a designated Medical Specialty, the consumer (and the AI engine) should be able to parse if that provider is trained/certified/boarded or not. HUGE difference. As the enumerated list of Medical Specialties grows, this really concerns me.

Current description: Any specific branch of medical science or practice. Medical specialities include clinical specialties that pertain to particular organ systems and their respective disease states, as well as allied health specialties. Enumerated type.

Proposed description: Any specific branch of medical science or practice that a person or organization has formal training, certification and licensing from an authority organization to practice medicine in that Medical Specialty. Medical specialities include clinical specialties that pertain to particular organ systems and their respective disease states, as well as allied health specialties. Enumerated type.

/cc @LeezaRodriguez

Diet, DietarySupplement ...
... these touch on other things too e.g. restaurants, menus, recipes, nutrition labels (see upcoming GS1 external extension) - possible some should be handled as core?

Comment from @RichardWallis :
schemaorg/schemaorg#492
several types that should probably remain as part of the core vocabulary, including:

• Dentist
• Diet
• Hospital
• Midwifery
• Muscle
• Nursing
• OcupationalTherapy
• Optician
• Pharmacy
• Physiotherapy
• Physician
• Patient
• PublicHealth
• Substance
• VeterinaryCare

Potentially it could be argued that MedicalBusiness should also remain in
the core as a foundation for all general medically associated businesses.

That is not to say that the could not be then extended within the health
extension. For instance Pharmacy could be a subtype of LocalBusiness in
the core, yet be in the domain of medicalSpecialty as defined in the health
extension.

Picked from Mark Woon:
https://lists.w3.org/Archives/Public/public-schemed/2015Jun/0004.html

Hi,
I'd would love to see support for genetics and pharmacogenetics in the
healthcare schema.
For example, there is no way to even provide metadata for genetics-based
dosing guidelines in MedicalGuideline right now. An example of such a
guideline can be found here: https://www.pharmgkb.org/guideline/PA166104997
I would like to propose the addition of these types:

• MedicalEntity
  • GeneticSequence
    • Gene
    • Genome
    • Variant
    • VariantCollection
      • Diplotype
      • Haplotype
      • Genotype
        The VariantCollection level is not really necessary, but all it's children
        contains a collection of Variants.
        I can go into more detail on exactly what I think these types should
        be/contain, but wanted to make sure there's consensus on the types that
        should be added.
        Thanks,
        -Mark woon

Current version

    <div typeof="rdf:Property" resource="http://schema.org/cause">
      <span class="h" property="rdfs:label">cause</span>
      <span property="rdfs:comment">An underlying cause. More specifically, one of the causative agent(s) that are most directly responsible for the pathophysiologic process that eventually results in the occurrence.</span>
      <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/MedicalCondition">MedicalCondition</a></span>
      <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/MedicalSignOrSymptom">MedicalSignOrSymptom</a></span>
      <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/MedicalCause">MedicalCause</a></span>
    </div>

Suggested

<div typeof="rdf:Property" resource="http://schema.org/cause">
  <span class="h" property="rdfs:label"> health:cause</span>
  <span property="rdfs:comment">Specifying a cause of something in general. e.g in medicine , one of the causative agent(s) that are most directly responsible for the pathophysiologic process that eventually results in the occurrence.</span>
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/MedicalCondition"> health:MedicalCondition</a></span>
  <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/MedicalSignOrSymptom"> health:MedicalSignOrSymptom</a></span>
  <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/MedicalCause"> health:MedicalCause</a></span>
  <link property="http://schema.org/isPartOf" href="http://health.schema.org" />
</div>

Thinking how to improve terms defined under MedicalSpeciality but labelled as adjectives:
eg. We currently have:
Surgical instead of Surgery
Endocrine instead of Endocrinology
Neurologic instead of Neurology
Renal instead of Nephrology
etc.

To be tracked under: schemaorg/schemaorg#492

Comments from Dan (#2): deeply re-work on the following properties

action (#18)
activityDuration
activityFrequency

for non-health activities, actions and events too?

• affectedBy, availableIn, cost, warning, ....

very broad wording. health only or more broadly applicable?
*birthPlace

vs. general / core treatment of people? (revisit family tree stalled work?)

calories
cookingMethod
cookTime

recipes stay in core? see #17

code
*always was v general, should we generalize it beyond health for core?
*we also have an related type spelled http://schema.org/Code

There's a redundant hierarchy for terms under 'MedicalEnumeration' declared at the same time under
'Enumeration'. However this hierarchy is obvious as 'MedicalEnumeration' is already :subClassOf :Enumeration.
This redundant declaration cause difficulties for inference cases.
eg.
Current version

:MedicalStudyStatus :subClassOf :MedicalEnumeration
:MedicalStudyStatus :subClassOf  :Enumeration
:MedicalEnumeration :subClassOf :Enumeration

Suggested

:MedicalStudyStatus :subClassOf :MedicalEnumeration
:MedicalEnumeration :subClassOf :Enumeration

Rationale:

:MedicalStudyStatus :subClassOf :MedicalEnumeration
:MedicalEnumeration :subClassOf :Enumeration

implies that:

:MedicalStudyStatus :subClassOf  :Enumeration

No need to declare that again.
This holds for other concepts as well: MedicalSpecialty, MedicalProcedureType, MedicalObservationalStudyDesign, MedicalImagingTechnique, MedicalEvidenceLevel, MedicalDevicePurpose, MedicalAudience, InfectiousAgentClass, DrugPrescriptionStatus, DrugPregnancyCategory.

Suggested improvement of its definition:
Current version

    <div typeof="rdfs:Class" resource="http://schema.org/MedicalEnumeration">
      <span class="h" property="rdfs:label">MedicalEnumeration</span>
      <span property="rdfs:comment">Enumerations related to health and the practice of medicine.</span>
       <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalIntangible">MedicalIntangible</a></span>
       <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Enumeration">Enumeration</a></span>
    </div>

Suggested

<div typeof="rdfs:Class" resource="http://schema.org/MedicalEnumeration">
  <span class="h" property="rdfs:label"> health:MedicalEnumeration</span>
  <span property="rdfs:comment">Enumerations related to health and the practice of medicine: A concept that is used to attribute a quality to another concept, as a qualifier, a collection of items or a listing of all of the elements of a set in medicine practice.</span>
  <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Enumeration"> schema:Enumeration </a></span>
  <link property="http://schema.org/isPartOf" href="http://health.schema.org" />
</div>

Would help to extend all datatypes predicates ranges by their corresponding XSD classes

Comment from @mfhepp:
schemaorg/schemaorg#492

The following properties have pretty generic names. There is a risk that we define them in the narrow sense of the medical / health domain. I would recommend to rename them so that it becomes clear that they are meant in the specific sense of this domain:

• action,
• algorithm
• aspect
• availableIn
• availableService
• branch
• cause, causeOf
• code, codeValue, codingSystem
• comprisedOf, connectedTo
• cost, costCategory, costCurrency, costOrigin, costPerUnit - also, how does this relate to PriceSpecification
• diagram
• frequency
• function
• manufacturer
• origin, originatesFrom,
• overview
• partOfSystem
• runsTo
• source, sourcedFrom
• purpose
• status
• usesDevice, warning

Action point from the 2015-08-28 meeting

I suggest we expand the domain of adverseOutcome and seriousAdverseOutcome to schema.org/MedicalProcedure.

Currently their domain is limited to schema.org/MedicalTherapy, yet clinical procedures can have (serious) adverse outcomes as well. Something which this webpage actually describes in structured data: http://www.cosmeticsurg.net/procedures/tummy-tuck/.

And something other sites publish about (by mentioning terms like risks, complications, side effects) without any relevant markup:
http://www.mayoclinic.org/tests-procedures/tummy-tuck/basics/risks/prc-20020325
http://www.webmd.com/beauty/tummy-tuck/cosmetic-procedures-tummy-tuck
http://www.realself.com/guide/tummy-tuck-procedure#Side_Effects

Picked from:
Create a new Food type (help further with foodWarning and recipeIngredient) #458

I am new to the community. I apologize if this has been a subject discussed in the past that I am not aware of. But in the even it has not been discussed, I thought I'd start a discussion. Thanks for your time.

With research and shopping behaviors changing in healthcare (including health coverage), it's assumed that more and more healthcare content will be created to help users navigate this changing landscape. I think adding / expanding health insurance as a type or extension of health.schema.org would be very helpful.

I see that the following both exist:
http://demoschemed.appspot.com/guarantor
http://demoschemed.appspot.com/insurance

I like the idea of being able to describe at the organizational or personal levels. But it seems as though health insurance could be described in far more detail. Could we describe the type of plan / coverage? High-deductible, Individual vs Family, Medicaid, Medicare, Vision, Dental, co-pays, coverage regions... While I think this would be valuable for those that offer coverage, I also believe it would be helpful on the provider side. Hospitals, physicians, urgent care, aggregators could markup their content when describing how their care interacts with coverage.

Thank you for your time!

Current version

:DrugClass :subClassOf :MedicalTherapy

Suggested

:DrugClass :subClassOf :MedicalEnumeration

Rationale:
Since the 'MedicalTherapy' is defined as a medical procedure it cannot have a 'DrugClass' (defined here as list item/concept) as children.

To take the 2 rdfa files and drop (remove) all lines used for classifications:
"Subclass of: CreatedInExtension"
"Subclass of: MaintainedInCore"
"Subclass of: MovedFromCore"

While we are preparing the health.schema.org extension, we need to revisit and restructure the initial submitted draft. A couple of predicates/classes have been already added in schema.org; and we need to list some predicates which will be moved to extension from core and vice versa.
The current RDFa file:
https://github.com/twamarc/ScheMed/blob/master/medicalEntity.rdfa

On the TO DO list we have also to document the following:
-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).

Current version

:Drug  :subClassOf :MedicalEntity

Suggested

:Drug  :subClassOf :Substance

Rationale:
'Substance' Class was suggested as parent of all medical/healthcare substances like 'Allergen', 'BiologicalSubstance', 'PharmacologicalSubstance' and 'ChemicalSubstance' .

Extension for Its definition is also suggested:

    <div typeof="rdfs:Class" resource="http://schema.org/Drug">
      <span class="h" property="rdfs:label">Drug</span>
      <span property="rdfs:comment">A chemical or biologic substance, used as a medical therapy, that has a physiological effect on an organism.</span>
       <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalTherapy">MedicalTherapy</a></span>
       <span>Source:  <a property="dc:source" href="http://www.w3.org/wiki/WebSchemas/SchemaDotOrgSources#source_WikiDoc">WikiDoc</a></span>
    </div>

Suggested

<div typeof="rdfs:Class" resource="http://schema.org/Drug">
  <span class="h" property="rdfs:label"> health:Drug</span>
  <span property="rdfs:comment">A chemical or biologic substance, used as a medical therapy, that has a physiological effect on an organism. Here the term drug is used interchangeably with the term medicine although clinical knowledge make a clear difference between them.</span>
  <link property="http://schema.org/isPartOf" href="http://health.schema.org" />
  <link property="owl:equivalentClass" href="http://purl.bioontology.org/ontology/SNOMEDCT/410942007"/> 
  <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/Substance"> health:Substance</a></span>
</div>

Action point from the 2015-08-28 meeting

Current version

    <div typeof="rdfs:Class" resource="http://schema.org/MedicalProcedure">
      <span class="h" property="rdfs:label">MedicalProcedure</span>
      <span property="rdfs:comment">A process of care used in either a diagnostic, therapeutic, or palliative capacity that relies on invasive (surgical), non-invasive, or percutaneous techniques.</span>
       <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalEntity">MedicalEntity</a></span>
       <span>Source:  <a property="dc:source" href="http://www.w3.org/wiki/WebSchemas/SchemaDotOrgSources#source_WikiDoc">WikiDoc</a></span>
    </div>

Suggested

<div typeof="rdfs:Class" resource="http://schema.org/MedicalProcedure">
  <span class="h" property="rdfs:label"> health:MedicalProcedure</span>
  <span property="rdfs:comment">A process of care used in either a diagnostic, therapeutic, preventive or palliative capacity that relies on invasive (surgical), non-invasive, or other techniques.</span>
  <span>Subclass of: <a property="rdfs:subClassOf" href="http://schema.org/MedicalEntity"> health:MedicalEntity</a></span>
  <link property="owl:equivalentClass" href="http://purl.bioontology.org/ontology/SNOMEDCT/50731006"/> 
  <link property="http://schema.org/isPartOf" href="http://health.schema.org" />
</div>

Rationale:
The definition change to cover all medical related procedure. In the extended definition we added 'preventive' and 'percutaneous techniques' replaced by 'other techniques'

Current version

:TherapeuticProcedure :subClassOf :MedicalProcedure
:TherapeuticProcedure :subClassOf :MedicalTherapy
:MedicalTherapy :subClassOf :MedicalEntity

Suggested

: MedicalTherapy :subClassOf :TherapeuticProcedure
: TherapeuticProcedure :subClassOf :MedicalProcedure

Rationale:
MedicalTherapy is a procedure and describes taking medications for treatment. So it fitts under therapeuticProcedure class, this one being itself under medicalProcedure class.
This would be a first step of rebuilding the MedicalProcedure entity to comply with common models and other medical terminologies: Snomed and HL7 standards

Comments from Dan (#2):
action:
propose adding muscleAction instead, and potentially removing the medical sense of 'action' (deprecate). The other sense is served ok by potentialAction already.

Current version

:VitalSign :subClassOf :PhysicalExam

Suggested

:VitalSign :subClassOf :MedicalSign

Rationale:
'VitalSign' is here defined as a sign not the assessment of the sign. So is fitting well in 'medicalSign' hierarchy and not in 'physicalExam' (which is a medical procedure).