Discussions on Medicine

Hi Iain,

The "notable" part of this type's title is quite deliberate, actually. Although Freebase does not require notability, this type's intent does, in the same way the Celebrity type requires a celebrity status and the Deceased Person type requires a dead person. As much as a notable person's medical conditions are news-worthy and publicly known today, Freebase is not the place to publicize health records of people not in the public eye, for privacy concerns and for relevancy reasons. Health care professionals guard patient information with the strictest confidentiality, in some cases leaving the decision to inform even family members in the hands of the patient alone. Freebase concur with this policy, and kindly request that privacy for personal medical data be respected. The "notable" part of the type title, you see, serves as a hint and a reminder for this policy.

OK, I sort of thought that might be the reason - good to have it explicitly stated. The scenario I had in mind was adding data for historical persons and then having it removed on bs wikipedia-esque "notability" grounds. I fully agree that sensitive data, particularly medical, and especially about living persons doesn't belong on a public database, with the exception of public figures who have made their condition public knowledge.

Perhaps worth adding something to the privacy policy to this effect?

IANAL but would 'public' be a better word than 'notable', as it has a legal understanding?

Rename it to something like "public figure with medical condition"? I'm all for it. I'll wait for anyone else to chime in, and change it tomorrow if nobody objects.

I'll talk to Kirrily about adding it to the privacy policy page. Thanks for the reminder.

A time-mediated CVT is an interesting idea, treating a medical condition as a sort of event, with start and end dates. Some medical conditions, however, don't have a clear start date, only a discovered or confirmed date. The cured part can be equally hard to measure, and the word "remission" is sometimes used because whether a recovery is temporary or permanent can only be determined with time. Nevertheless, for acute diseases or injuries, I suppose we can capture start/end dates.

What do others think?

There's no reason we can't have a Plant Disease type. In fact I think it's a great idea.

It wouldn't be in the Medicine domain though (see domain scope post). How about starting a Phytopathology domain?

Sounds good to me (though I don't know if I'm up to starting it myself).

At least some of the relevant Wikipedia topics seem to be about both the disease and its cause.  Do we want to separate these two (as I think we usually do for human diseases)?

A suggestion is that you call the base by the more colloquial term of "Plant pathology" instead of "Phytopathology". Many university departments use this name too.

The Wikipedia article for Plant Pathology has some good information that could be used to structure a base.  In particular, I could see a "Plant Disease relationship" CVT (or more general "Disease relationship") based on the following quote: "The "Disease triangle" is a central concept of plant pathology. It is based on the principle that infectious diseases develop, or do not develop, based on three-way interactions between the host, the pathogen, and environmental conditions."

I've now created a Plant Pathology base which includes a Plant Disease type and a CVT for disease, cause and conditions.  I've filled in some of these values for this topic.

Any comments welcome, since it's a long time since I've created any types!

Thanks! I've changed it as per your suggestion, except that I couldn't limit the "Plant disease" property to a single value.  I've made you an admin of the base if you want to try and/or make any other updates.

(Is it still a triangle?  Should we call it a quadrilateral instead? :) 

Cool. The schema editor is acting weird. I tried removing the only "Plant disease" topic, which should free up the schema to reset to 1 value. That didn't work. I then tried deleting the property so I could add it back as restricted to 1 value. That didn't work either. Both issues are new bugs.

The only other change that I would suggest is adding a new topic called "Plant disease host" that includes "Organism classification" so that you can reciprocate the link to the CVT with host.

(Disease pyramid?)

Hello and welcome to Freebase!

I think what you're bring up is the ability to differentiate between what a layperson may consider as a sign of a medical condition (congestion, fatigue, fever and you will probably first suspect you've got a cold or the flu), and diagnostic measures that would solidify that suspicion (high or low white blood cell count via a blood test, etc.).

The problem with separating the two into separate properties are two-fold. First, the line between what a patient may notice as a symptom and what a doctor may notice is quite blurry and if presented as two properties, we'll likely end up with the same data in both places. Second, doctors do take patient-reported symptoms into account during diagnosis, which make them part of the diagnosis. Imagine a doctor coming to the conclusion that someone has a cold or flu if that person isn't exhibiting any of the commonly known cold/flu symptoms, not to mention ordering a blood test without a hint of necessity or knowing what you're looking for -- that would be rather unlikely indeed.

We could use a new type /medicine/finding to assert on results of medical tests, eg., (790.1) Elevated sedimentation rate, or (790.21) Abnormal fasting glucose).

Medical findings are somewhat distinct from symptoms in that they are associated with a specific medical test (typically performed by a medical professional). Also, someone could be asymptomatic for a disease, but be positive on one or more medical tests. 

As Faye discusses, there is a bit of a grey area with some findings on physical exam. My guess is that we make anything a symptom if it's noticeable by the patient or others involved with the patient (family members, etc)

 /medicine/finding would have a property for the disease it's caused by, the test or tests it's associated with, and possibly a phylogeny pattern of includes_findings and parent_finding. 

I added /medicine/diagostic_sign and /medicine/diagnostic test.

See Lumbar Puncture as an example. 

 At some point, we may want to add another type /medicine/medical_procedure, to include therapeutic procedures, and to hold CPT codes. We would assert  /medicine/medical_procedure on most topics of type /medicine/diagnostic test.

Need to figure out how to handle Medical treatments.  Presumably, some of these would be co-typed with /medicine/medical_procedure.

I think there's a CVT relationship involving the testable attribute of a disease, the test, and the disease itself, not expressable via simple properties as is the current model.

For example, low glucose in CSF shouldn't read as sign of the test lumbar puncture, as on the lumbar puncture topic page. Rather, low glucose in CSF is a diagnostic sign of meningitis, measurable via a lumbar puncture. 

On the meningitus page, instead of having a "sign" property pointing to low glucose in CSF, a better way to present it would be via "diagnosis" consisted of the CVT with the diagnostic finding (low glucose in CSF), and the test (lumbar puncture).

As for a medical procedure, what properties will they have?

Great idea.

i created a Diagnostic Test Sign CVT.

Lumbar Puncture has some example data.

Hi Spencer, sorry I didn't catch this until now.

Are you referring to your Infectious Disease type? I like it! I modeled something similar a long time ago but can't seem to find it anymore. One question: "vector" to me is a method of transmission; isn't it already covered by the "transmission" property?

I'd like to have Jeff take a look at it too. Once that happens and we've resolved the "vector" property discussion, I think we should promote it to the Medicine domain!

hey thanks faye,

 i like your idea about merging the vector and transmission properties..... let me sit on it for a day, then change it.

Here's a possibly unrelated weirdness: There are a bunch of views for infectious diseases in the Infection base, but all the types are actually in the Disaster2 base. Is this on purpose, or is there some funny bug going on here?

And to clarify my +1 vote, now that I see where these types are actually living, I think the infectious disease, vector of disease (although I think "disease vector" might be a better name), Route of infection transmission, and Type of infectious agent types should be promoted to the medicine commons. Epidemic should stay in a disaster domain, I think. I'll write up a Jira task for the promotion if Faye and Spencer agree with this.

Now I've given it more thought, I think disease vector should remain separate from route of infection transmission. So infectious disease can be promoted to Medicine without changing the schema.

Also +1 on the promotion of route of infection transmission, and type of infectious agent, although I'd like to rename the last type to avoid the loaded word "type", and call it something like "category of infectious agent".

+1 all.

i amped-up its descriptions.

ideally i would like this to be used to also map non-human diseases, but theres no non-anthropomorphic disease topic so i've just cotyped disease  and will forget  all about this for now.

we could do a sweet 'genetic disease' type too...

Promotion task created: DA-853

Genetic disease sounds fun; what properties would it have, though?  Genes can already be disease causes.

Hi Spencer, isn't a Drug a Medical Treatment?

The medical treatment type seems a bit under-specified to me.  

 As skud says, there are certainly substances that are drugs that shouldn't be called medical treatments, but even drugs that are often used to treat illness aren't medical treatments all by themselves.  

For a drug to be a medical treatment, I'd say you need to indicate additional properties like required dose.  Depending on this and other properties the same drug could be a medical treatment, a poison, or a recreational drug.  

Sigh, dosage. Frankly, the challenge there is not schema or data, but accuracy and completeness. Side effects and warnings would need to be modeled before dosage could be responsibly posted. Even then, it's "x or as prescribed by your physician", and that's not even taking into consideration what other drugs a person may be taking. When it comes down to it, dosage is not a universal hard fact as it is a personal situation kind of data.

Included type can be removed from individual instances. Sure, not 100% of drugs are medical treatments, but not 100% of visual artists are human either. In that case, the included type that doesn't apply can be removed.

ok, sure, i see what you are saying.  Sorry to cause you to sigh ;)..

I was thinking of a more detailed use case than maybe is appropriate?

I was thinking about modeling a medical treatment in the case of a clinical trial - in that case it would be very important to capture things like dosage and all the information should be both static "facts" and readily accessible. 

I like the idea for /medicine/medical_test: +1.

I disagree that /medicine/medical_test should be cotyped /medicine/medical_treatment. In fact, I think they're pretty much distinct: there are tests, and then there are treatments. Test are diagnositc tools, while treatments are or should be only used once there is a diagnosis.

I'm not a lawyer (or a Freebase/Metaweb employee), but the two potentially problematic clauses that I see are:

"c. You shall not assert any proprietary rights to any portion of the database, or represent the database or any part thereof to anyone as other than a United States Government database.

...

e. ...  Some ClinicalTrials.gov data may be subject to the copyright of third parties and you should consult these entities for any additional terms of use."

Clause c) is a restriction which is not enforced by the Freebase license and could not be passed through to downstream consumers.  Clause e) basically means that you can't rely on having any right to use the data at all, making the rest of the terms and conditions pretty much worthless.

Also, since their site is updated nightly and they request people not to make static copies of the database, I think there's a potential liability issue if you aren't updating nightly as well.

p.s.  One could argue that the "non-commercial" restriction asserted by the LinkedCT license violates the "no proprietary rights" clause of the original ClinicalTrials.gov license.

Yes, I agree about these "potentially problematic" clauses as well as the potential conflict of the non-commercial restriction on the linkedCT data.  

The problem is that it seems basically impossible to translate the "potentially problematic" into clear answers to questions of what can be done with this data without a lawyer.  I'm really hoping that freebase staff (who have to be familiar with this scenario by now and must also include actual lawyers) can bring some clarity to these issues.

Typically, US Govt data is public domain (provided it isn't classified) -- Sometimes the government disagrees, and people like Carl Malamud pry the data open to the benefit of the world.

All of that said, though, I agree with Tom that this particular data set is particularly difficult as it seems to blend data together without sufficient metadata to tease it apart (say, remove the data created by the government from the commercial sources.)  Even if we could separate the data by source, we would have to work with each of those data providers to see if they would release the data under a freebase-compatible license.  So far, we have seen only moderate success with this approach after great effort.

As an aside, we are considering allowing NC data into Freebase.  It would require some technical development to keep a clear partition between the current Freebase data and the data under a more restrictive license (mostly so a commercial user doesn't accidentally use NC data).  It would also require changes to our TOS.  We don't have a set plan to do this yet, but we're collecting use cases that would benefit from these changes. 

Which dataset are you referring to here, the LinkedCT version or the original one from ClinicalTrials.gov or both?  The LinkedCT incorporates more sources and hence appears more legally complex.

ClinicalTrials.gov is a service of the national library of medicine and the national institute of health.  I hope (don't know) that they would be amenable to having their data made more visible and more useful.  It seems to be a similar situation to when the linkedct dataset was constructed and published except linkedct added a more restrictive license rather than a less restrictive one (and unfortunately their site is still non-functional).

I have a query into NLM about this - hopefully they will respond soon.  

As an aside, I have been wanting to contribute to freebase since it got started, but every time I start, I find myself in exactly this predicament.  As a developer-type, I just can't bring myself to type in data when it is sitting right there to be imported automatically but I keep getting stalled by legal ambiguities (and thus losing momentum and interest).  I wonder if it would be possible to put up a list of patterns (i.e. of importing/'touching'/enhancing/integrating) that would yield clearly legal freebasable content from public data sources with unclear licenses. 

OK, I understand better that you are talking about two distinct data sources.

The legal ambiguities are often a problem.  However, if it is from the US Federal Government, then there really are no ambiguities.

I'm not sure I understand your patterns idea beyond "importing".  Could you explain that a little more?

The patterns I was thinking of include things like the Geographer application.  

When there is a clear fact about the world (like the latitude and longitude of a particular address) that could in principle be gathered from many sources but where those sources have attempted to assert (or accidentally asserted) some manner of ownership over the fact, what needs to be done to bring that fact into the freebase context?  

For example, a pattern for a developer looking at a data source with ambiguous licensing could be something like this:

1) write the script that would gather the facts and load them into freebase

2) Before loading each fact, present it to a freebase user via some manner of mechanical turk style application like TypeWriter and have them 'approve it'

Presumably having this approval process or another value-adding one somehow changes things...  As a potential developer of processes like these, it would be useful to know what specifically is ok and what to avoid.

Not to be a kill joy or anything, but I'd be careful with even the data from ClinicalTrials.gov.  They are hosting the data, but they allow others to contribute it and clause e) is specifically about this case, where they warn that others may claim copyright to it and have other terms of use.

Also, I'm not sure the proposed "data laundering" operation would pass much scrutiny if the original data was actually subject to a valid copyright.  What the NIH really should have done is made it a requirement that the data providers license the data for reuse if they wanted to have it included in the web site.

What you probably could do is ask the NIH/NLM how to identify which data is produced by the U.S. Federal Government and is thus free of copyright.  That would allow you to screen out any potentially problematic data.

For example, the data for this study is probably all free and clear:

      National Cancer Institute (NCI)

  National Institutes of Health Clinical Center (CC)

    United States: Federal Government

You could ask them which of those XML fields you should be looking for an what values indicate that the source is free of copyright.  The field seems like a likely candidate, but unfortunately it doesn't seem to be available in search or display on the web, so you need to look at the raw XML.

UGH! Looks like the editor doesn't like angle brackets, but doesn't warn you that it's going to strip things that look like XML tags.  Let's try again with square brackets...

--------- 

For example, the data for this study is probably all free and clear:

  [sponsors]

    [lead_sponsor]

      [agency]National Cancer Institute (NCI)[/agency]

    [/lead_sponsor]

  [/sponsors]

  [source]National Institutes of Health Clinical Center (CC)[/source]

  [oversight_info]

    [authority]United States: Federal Government[/authority]

  [/oversight_info]

You could ask them which of those XML fields you should be looking for an what values indicate that the source is free of copyright.  The [source] field seems like a likely candidate, but unfortunately it doesn't seem to be available in search or display on the web, so you need to look at the raw XML.

Tom, thanks for killing my joy :)  .  Much better than going to jail and good suggestion for this chunk of data.  I will give them another day to respond to my last inquiry and then fire off another one.  Feel free to add your voice to pestering them - I'm sure it would help move things along to have multiple requests (and I will do the work of importing what looks like extremely useful and interesitng data once its approved).  Here is the link to the contact form: http://clinicaltrials.gov/ct2/helpdesk?hd_url=http%3A%2F%2Fclinicaltrials.gov%2Fct2%2Fhome

I still think that some general guidelines for legal patterns of data laundering (if any exist) would be really useful if they could be well articulated.

I updated DA-642, but thought I would repost here as well:

I created a simple, non-reciprocated property for /medicine/disease, namely "associated advocacy organizations", on sandbox:

http://www.sandbox-freebase.com/type/schema/medicine/disease

I filled out a couple of topics:
http://www.sandbox-freebase.com/view/en/autism
http://www.sandbox-freebase.com/view/en/cancer

Comments/objections before I promote it to production?

Another note: with this property added, I think it would make sense to deprecate the use of the organization sector type to link an organization to a disease. For example:

http://www.sandbox-freebase.com/view/en/autism 

thanks faye.

i'm having second thoughts about this idea actually.

if we do it this way, we should reciprocate it i think.  that way Autism Network International links to autism, and it could properly cotype 'organisation' . i say things should always be reciprocated, even when its awkward, like 'medical condition advocate organisation'.

but then, why not just be using  organization sector? this is what its intended for isn't it? err, i didnt realise 'sector' meant 'subject'. i should've read the description.

maybe it covers it then, unless we think 'advocacy' is different enough from 'sector' to warrant different treatment, or medical conditions should be treated uniquely, which i think is a nuance we can safely drop.

Spencer,

I actually would prefer to drop this property and continue to use "organization sector" to capture support/advocate organizations for diseases. First because capturing an organization's focus is a generalized use case not restricted to diseases, and secondly because otherwise a reciprocal link back from disease to organization would require a new "disease advocate organization" type that'd start a bad precedent for subject-specific data types that are otherwise identical to more general types. My fault for not bringing this up in the first place -- I thought concensus had already been established on adding a new property linking disease to support organization.

Now that's been clarified, if there's no objection, I'd like to scrap this new property, and keep using "organization sector" instead. In face, we could probably extract and load most of the advocate organizations in Wikipedia to Freebase.

k i'm on it: http://www.freebase.com/view/en/aids?pid=%2Forganization%2Forganization_sector%2Forganizations_in_this_sector

sorry, this was originally my idea in the first place.

Finally! :)

On Person, I'd like to throw "Afflicted medical conditions" out there as a property name contender. Otherwise, go for it!

I'm concerned by having this on /people/person.  Seems kind of tactless and privacy-invading.  I'd rather there were a type in /medicine for "Afflicted person" with a description explaining that it's for well known people who are publicly known to be afflicted with a disease or condition.  That type would of course include Person.

It's a bit like Deceased Person -- it was created, as I understand it, because it seemed to be bad taste to have "Date of death" on living people's topic pages.

I'm with skud.  Imagine it was 20 years ago and people users were adding HIV status assertions (true or not).

We should be very careful about this.

There's nothing that prevents a user from entering, today, the cause of a politician's death as AIDS, the sexual orientation of an actor as gay, or some person as the secret lovechild between a famous religious leader and a staff member of his charity.

I understand the concerns for privacy and for insertion of false assertions (either intentional or otherwise) on Freebase and I applaud the effort to address both. We could isolate the schema and construct it such that exposure is minimized. At the end of the day, though, this is still an open database anyone can edit. We need to be able to trust the Freebase community to address and correct misinformation, whether through automated detection tools, or through old-fasioned monitoring and manual correction.

Although I made the "Diseased Celebrity" type comment as a joke, it's beginning to make more sense.  How about something along the lines of "Notable person with this disease".

-r

p.s. I swear I wasn't the one who asserted Senile Dementia on various Metaweb staff members.

Hi, thanks for the sugguestion. I'm assuming these properties are proposed for the Drug type. What should be the expected type of the MOA property?

Regarding dosage, it's something that I've considered before and struggled with. On the one hand, I think dosage is standard data to have on a drug. On the other hand, modeling dosage with a simple compound value type like "frequency: once a day, pills each time: 2" without the ability to put a giant asterisk with a footnote of "please consult a medical professional" or "unless prescribed differently by your doctor" -- as you would in an article with free text capabilities -- seems rather irresponsible.

The bottom line is that the recommended dosage is not "one size fits all", and I'd like to come up with a way to model something like this that may not apply 100% of the time, without the ability to provide a proper context similar to or including the lengthy disclaimer seen on a drug's packagaing. I am concerned about the consequences of having incorrect or incomplete data. The admins of this domain are not certified medical staff, and correction or even detection of grossly off assertions, can be difficult.

What does everyone else think? Should we have dosing info for drugs, and if so, how would you model it?