lower limit of detection

[timbrisc]

Issue migrated from trac ticket # 5820

component: organization | priority: minor | keywords: LLOD

2022-06-07 20:34:29: william.hess@fda.hhs.gov created the issue

---

UCUM Board needs to provide input on this. UCUM already has "Limit of flocculation" so adding a UCUM term called "lower limit of detection" would be somewhat consistent. Limit of detection, LOD is the lowest concentration that can be measured (detected) with statistical significance by means of a given analytical procedure.20 It is a measured quantity value, obtained by a given measurement procedure, for which the probability of falsely claiming the absence of a component in a material is β, given a probability α of falsely claiming its presence.1 Practically, it is determined on the basis of the noise level: it is most often three times as high.

This new concept is needed to support the U.S. Food and Drug Administration Pharmaceutical Quality Chemistry Manufacturing and Control (PQ/CMC) initiative. Please see https://www.regulations.gov/document/FDA-2022-N-0297-0001, which in part, states:

"PQ/CMC is a term used to describe manufacturing and testing data of pharmaceutical products. PQ/CMC encompasses topics such as drug stability, quality specification, batch formula, and batch analysis, which are important aspects of drug development. PQ/CMC plays an integral part in the regulatory review process and life cycle management of pharmaceutical products. The development of a structured format for PQ/CMC data will enable consistency in the content and format of PQ/CMC data submitted, thus providing a harmonized language for submission content, allowing reviewers to query the data, and, in general, contributing to a more efficient and effective regulatory decision-making process by creating a standardized data dictionary.

The impetus for this standardization effort was the provisions from the 2012 Food and Drug Administration Safety and Innovation Act (Pub. L. 112-144), which authorized the Agency to require certain submissions to be submitted in a specified electronic format. PQ/CMC standardization supports FDA's regulatory needs in receiving structured and standardized data in pharmaceutical quality and includes two objectives: (1) To standardize the pharmaceutical quality data that is currently received by FDA in eCTD Module 3 from the sponsoring organizations, and (2) to use these structured elements and develop a FHIR data exchange solution."

[dr-shorthair]

This concept is not a unit-of-measure, it is a quality measure or part of the description of a measurement-procedure.

[gschadow]

We have one advisor moving to reject. I could concur. And the issue would be closed. So how is this done now?

246

[dr-shorthair]

1. come to consensus
2. someone hits the 'close issue' button.

What is our process for 1. ? Who should have the power for 2. ? (currently I think it is only @timbrisc)

[chgessner]

Missing here are the steps to publication that are due to happen after "consensus". Publishing comes before or after an issue is closed? Maybe this is a good guideline, also includes some technical guidance for using github in such a process: https://confluence.hl7.org/display/FHIR/HL7+Process+for+Publishing+a+FHIR+IG

[gschadow]

I am frustrated that all of that was just thrown away from Trac.

The way it should be is a workflow status, here it is from the old UCUM trac system. State transition model:

accept = new -> assigned
leave = * -> *
propose_reject = new -> reject_proposed
reassign = new,assigned,reopened -> new
reconsider = reject_proposed -> reconsidered
reject = reject_proposed -> wontfix
reopen = closed -> reopened
resolve = new,assigned,reopened -> closed

With the following actions:

accept.operations = set_owner_to_self
leave.default = 1
leave.operations = leave_status
reassign.operations = set_owner
reopen.operations = del_resolution
resolve.operations = set_resolution

And permissions

accept.permissions = TICKET_MODIFY
propose_reject.permissions = TRAC_ADMIN
reassign.permissions = TICKET_MODIFY
reconsider.permissions = TRAC_ADMIN
reject.permissions = TRAC_ADMIN
reopen.permissions = TICKET_CREATE
resolve.permissions = TICKET_MODIFY

With this resolution is as easy as pushing a button. Select the resolution you in tend and it will move the process ahead.

Normal paths are:

1. propose_reject = new -> reject_proposed
2. reject = reject_proposed -> wontfix (CLOSED)

or

1. propose_reject = new -> reject_proposed
2. reconsider = reject_proposed -> reconsidered

then ultimately someone has to do something:

1. accept = new -> assigned (to self) 2, bunch of normal updates and commits ultimately
2. solution_proposed
3. solution_implemented
4. resolved (CLOSED)

Easy stuff. You guys were pushing git saying it could do everything Trac can do. So where is this now?

[gschadow]

As for the questions of publishing, again, it is easy. And it has been made terribly complicated.

There is a trunk, every committer checks that out, while working on an accepted ticket, you make commits to that one trunk.

You declare your change closes the ticket. With the Trac workflow it is super easy to add even review processes where commit would be checked by another.

When making new release, create a release engineering branch, stable, review all changes here since last time, all changes have tickets that describe them. Any open ticket needs to be either finalized or their changes revoked from that stable branch.

Once done final testing and review begins (tags: alpha, beta1, 2, release candidate rc1, rc2, release, if need be all these steps could be followed, but of course we do not have this need. So after review, possibly advisors and technical staff would all sign off (again by clicking buttons). Once everybody has signed off, that is tagged as the release.

That is how it should go.