Problem

parse_doi in medline_parser.py loops over every <ELocationID> and unconditionally reassigns doi on each iteration. Any ELocationID whose EIdType is not "doi" resolves to "". So when a record lists the doi entry before another type (commonly pii), the trailing entry overwrites the already-parsed DOI with an empty string.

Real example — PMID 24746000:

<ELocationID EIdType="doi" ValidYN="Y">10.1016/S2213-2600(14)70019-0</ELocationID>
<ELocationID EIdType="pii" ValidYN="Y">S2213-2600(14)70019-0</ELocationID>

parse_medline_xml returns doi == "" instead of 10.1016/S2213-2600(14)70019-0. This doi-then-pii ordering is very common in PubMed, so a large number of records silently lose their DOI.

There is also a second, related bug: the PubmedData/ArticleIdList fallback is in the else branch of if len(elocation_ids) > 0, making it unreachable whenever any ELocationID is present — even if none of them is a DOI (e.g. a record that only has a pii ELocationID but carries the DOI in ArticleIdList).

Current code

if len(elocation_ids) > 0:
    for e in elocation_ids:
        doi = e.text.strip() or "" if e.attrib.get("EIdType", "") == "doi" else ""
else:
    article_ids = pubmed_article.find("PubmedData/ArticleIdList")
    ...

Fix

• Iterate ELocationID and stop at the first EIdType="doi" entry, so a later non-doi entry can no longer clobber it.
• Always fall back to PubmedData/ArticleIdList when no DOI was found in the ELocationID list (covers records that only have e.g. a pii entry).

Tests

Added a regression test (test_doi_with_trailing_pii_elocation_id) using PMID 24746000, whose <Article> lists doi before pii. It fails on the current code and passes with the fix.

Verified the new logic against four cases — doi-before-pii, pii-only with DOI in ArticleIdList, pii-before-doi, and no-DOI-at-all — all behave correctly, and the no-DOI case still returns "".