Stream: COVID-19 Knowledge Accelerator
Topic: COKA API
Khalid Shahin (May 12 2020 at 20:10):
Citation resource example: https://gps.health/coka/resources/Citation/1
Grahame Grieve (May 13 2020 at 21:19):
the citation resource seems really heavy weight compared to what I expected.
- One particularly obvious issue is that it doesn't use HumanName and Address.
- I'm not familar with contributers as a concept appart from authors?
- when would you use alternative forms? *
Grahame Grieve (May 13 2020 at 21:19):
a more general question: surely some other group has defined an interoperable format for citations?
Brian Alper (May 13 2020 at 22:56):
Regarding HumanName: Authors in citations have extensive structure in MEDLINE XML DTD and citation resources (developed to meet the needs of sharing citations in communities using MEDLINE as a common base/authority) have a greater need for and mapping of data mapped in this way. In addition to the mapping of name elements in existing citations there is also a need to handle "group names" as an author. We could consider adding an addiitional optional element such as author.humanName as an alternative form of expression which could re-use FHIR data where available.
Brian Alper (May 13 2020 at 22:57):
Regarding Address: We can easily change datatype for address to Address. Where data is often shared as a simple string it can use Address.text
Brian Alper (May 13 2020 at 23:02):
Regarding contributorList: There is a substantial effort in academic developments (unevenly distributed) to apply contributorship instead of and/or in addition to authorship. There is a CreDiT Taxonomy (https://jats4r.org/credit-taxonomy) included in NISO JATS (Journal Article Tag Suite) standard. We could consider changing contributorList datatype from a BackboneElement to a Contributorship Datatype. (We did something similar changing Statistic Resource to Statistic Datatype.)
Brian Alper (May 13 2020 at 23:05):
Regarding alternativeForm: A journal article may be published in both print and online versions. There are times when there are actual differences between the two in the content and frequent instances where the publicationDate is different between the two. But these situations are not considered separate citations.
Brian Alper (May 13 2020 at 23:08):
Regarding interoperable format for citations: We reviewed MEDLINE XML DTD, JATS (NISO standard) and RIS tags (commonly used by citation managers) and none of these formats are universally used across the groups managing citations today and they do not meet the needs support citations across multiple research collections right now for COVID-19 datasets.
Grahame Grieve (May 13 2020 at 23:19):
is there any reason for this not to apply to FHIR doing a citation format?
Grahame Grieve (May 13 2020 at 23:19):
Grahame Grieve (May 13 2020 at 23:20):
when I see Author.lastName, foreName, suffix, initials, collectiveName, I say - looks like a humanName to me, but with different names for the same things. Why?
Grahame Grieve (May 13 2020 at 23:21):
I do wonder why authorList and contributorList are actually different elements - they're pretty much the same type
Brian Alper (May 13 2020 at 23:26):
We can explore remapping the author name elements to humanName (containing use, text, family, given, prefix, suffix, period), initials, and collectiveName. The differences are mostly 1:1 mapping. The addition of initials and collectiveName are needed because they are not found in HumanName Datatype.
Grahame Grieve (May 13 2020 at 23:28):
collectiveName = HumanName.text, I think. And initials.. just just HumanName.given
Brian Alper (May 13 2020 at 23:29):
There are times when some contributors are not authors and both concepts are accounted for. By the time you manage separate overlapping lists it seems easier to manage them as separate elements. The actual data in systems today often uses one or the other of these lists so the data is structured to fit one or the other. Forcing a combination will likely cause a lot of confusion when trying to do both.
Brian Alper (May 13 2020 at 23:31):
The data for author names may include "given" and "initials" so you can not use the same element for both constructs. If collectiveName is used in existing systems today and it is converted to HumanName.text it is (1) inaccurate as it is not a human name and (2) loses the structured knowledge that it is a collective name.
Grahame Grieve (May 13 2020 at 23:31):
well, there's a difference between combining lists (which I wasn't suggesting) and combining types so you only define the one structure - they only differ by the addition of telecom and the flag for corresponding author
Brian Alper (May 13 2020 at 23:34):
You could potentially combined authorList and contributorList into one contributorList with one new element (type that lets you set whether the list is author list or contributor list or both combined) and a cardinality adjustment to 0..2 so that you could have 2 lists if you wanted to.
Grahame Grieve (May 13 2020 at 23:35):
well ,I would have two lists author 0..* and contributor 0..*, and then the type for contributor would be @author
Grahame Grieve (May 13 2020 at 23:35):
I think.
Brian Alper (May 13 2020 at 23:39):
There is authorList 0..1 which contains author 1.., and contributorList 0..1 which contains contributor 1.. -- it seems like for each list you either have a list or you don't (so combining them would be 0..2 at the list level). If you have a list it can have any number of entries but 0 entries would be meaningless.
Brian Alper (May 13 2020 at 23:39):
1..* does not show the 1..Asterisk in the note above
Brian Alper (May 14 2020 at 15:31):
@Grahame Grieve we worked thought the combination of authorList and contributorList concepts and think your idea of a common datatype will work very well. The Citation Resource can be reduced to 2 simple lines for this area:
Brian Alper (May 14 2020 at 15:31):
This could be changed to:
authorList 0..1 AuthorList
contributorList 0..1 AuthorList
Brian Alper (May 14 2020 at 15:32):
Then the AuthorList Datatype can include:
complete 0..1 boolean
entry 0..* BackboneElement
humanName 0..1 HumanName
initials 0..1 string
collectiveName 0..1 string
identifier 0..* Identifier
contribution 0..* CodeableConcept
affiliationInfo 0..* BackboneElement
affiliation 0..1 string
role 0..1 string
identifier 0..* Identifier
address 0..* Address
telecom 0..* ContactPoint
correspondingAuthor 0..1 boolean
listOrder 0..1 positiveInt
summary 0..* BackboneElement
source 0..1 CodeableConcept
value 1..1 string
Rob Hausam (Jun 11 2020 at 15:01):
At first glance, that looks like a pretty "verbose" data type (but we do have some precedent for that - I'm thinking of Dosage). One farily minor point, I'm wondering whether instead of the 'humanName' element, it should just be "name 0..1 HumanName" (similar to Patient.name)?
Khalid Shahin (Jun 11 2020 at 18:53):
Rob Hausam said:
At first glance, that looks like a pretty "verbose" data type (but we do have some precedent for that - I'm thinking of Dosage). One farily minor point, I'm wondering whether instead of the 'humanName' element, it should just be "name 0..1 HumanName" (similar to Patient.name)?
Hi Rob, and yes we already changed humanName to name as seen in the FHIR build: http://build.fhir.org/citation.html
edit: Also, we decided not to make AuthorList a DataType.
Last updated: Apr 12 2022 at 19:14 UTC
