#203: Process to finalize a terminology
-----------------------+----------------------------
Reporter: lv | Owner: preeder
Type: problem | Status: new
Priority: major | Milestone: data-quality2
Component: data-stds | Resolution:
Keywords: alignment | Blocked By:
Blocking: |
-----------------------+----------------------------
Changes (by lv):
* cc: gpc-dev (removed)
* cc: gpc-dev@… (added)
Comment:
Fixing cc; Adding discussion based on meeting minutes 12/9/14.
--
From: gpc-dev-boun...@listserv.kumc.edu [mailto:gpc-dev-
boun...@listserv.kumc.edu] On Behalf Of Dan Connolly
Sent: Thursday, December 11, 2014 5:31 PM
To: Phillip Reeder; gpc-dev@listserv.kumc.edu
Subject: RE: approving GPC terminologies: data-domains2 and group decision
making
Yes, please do take ownership of the diagnosis modifier ticket (#90) and
medication modifiers ticket (#199); I'm sure Laurel and Alex won't mind
you taking work off their plates. Be sure to point to exactly which file
on central desktop contains your proposal.
As to closing them, the norm/plan is to have the vocabulary loaded on
babel as well so that others can browse around. Would you like Nathan or
me to set you up with an account to do that? Otherwise, assign the ticket
to one of us and we'll upload to babel.
A ticket doesn't have to be closed to get on the agenda. Substantive
progress can do that too.
Or you could try closing without a copy on babel, presuming that the
downstream stuff will more or less take care of itself. (But I can almost
guarantee that Nathan or I won't get around to something without a ticket
assigned to us.)
On freezing... I neglected to give the short version of the current
process: if a ticket has been closed for a week or two, it's agreed by the
group. Then it gets more frozen as sites deploy it, since we gain
confidence through the experience and the cost of changing increases. I
can't think of any useful improvements on that, but I'm open to
suggestions.
--
Dan
--
From: Phillip Reeder [phillip.ree...@utsouthwestern.edu]
Sent: Thursday, December 11, 2014 5:09 PM
To: Dan Connolly; gpc-dev@listserv.kumc.edu
Subject: Re: approving GPC terminologies: data-domains2 and group decision
making
Regarding “How do you know when something is Final?”, Final doesn’t have
to be set in stone, because there is always new information that can come
along, but we can consider something final and freeze it, allowing for
sites to take it and start implementing it. That’s the finalized I’m
looking for. We already know we will have a next version of the
terminology with additional data domains, and changes.
So, with regard to diagnoses and medication modifiers, I have uploaded a
slight modification of the diagnosis modifiers terminology to central
desktop. It also includes the medication modifiers I had previously
proposed. Medication modifiers are mostly just source of data modifiers.
To get these accepted as the Final GPC Terminology V1 modifiers for
demographics and medications, should I take ownership of the diagnoses
modifier terminology ticket and medication modifier terminology ticket and
close them, which should move them to the agenda for next week?
There are a bunch of terminologies on Central Desktop. Maybe we should
add a GPC V1 Terminology folder where we can put the approved
terminologies?
The January 15th date for the milestone:data-domains2 is going to be here
before we know it, especially with the holidays coming up.
Phillip
--
From: Dan Connolly <dconno...@kumc.edu>
Date: Thursday, December 11, 2014 at 1:33 PM
To: "gpc-dev@listserv.kumc.edu" <gpc-dev@listserv.kumc.edu>
Subject: approving GPC terminologies: data-domains2 and group decision
making
In the Dec 9 notes, I see some questions about the process of approving
terminology.
It's somewhat evolving, but a week or two I collected my notes in
milestone:data-domains2:
As discussed Oct 28 (notes: #12) priority domains for this milestone are:
• GPC Demographics #67
• GPC Diagnoses #63
• GPC Vitals #23
• GPC Meds. #78
• Cancer Tumor Registry #185
In each case, the goals are to:
• agree on design, including
o which clinical workflows the data comes from
o ETL details such as Epic clarity tables or NAACCR ETL scripts
• deliver metadata in i2b2
o as .csv via cdt for sites to use (#76)
o on babel for browsing (#1)
Regarding "How do you know when something is final?" it can only be final
when there is no possibility that new information will arise that merits
revising the design.
There's a risk of doing work based on a design that changes, but also, as
noted on the call, there's an incentive to get involved early. (cf The
Economic Importance of Standards by Tim Berners-Lee).
Regarding "If a ticket is being closed - item is approved and that was the
standard" that's close, but let me clarify: the owner of a ticket is to
close the ticket when they believe they have completed the task. The
reporter (aka customer) of the ticket gets notification that the ticket
was closed and reopens if if they're not satisfied.
Anyone who doesn't agree can reopen the ticket.
Closing a ticket doesn't imply agreement by gpc-dev as a whole, though. It
puts the ticket on the agenda of the next teleconference. Typically, the
ticket is closed in a way that doesn't merit discussion, and it's just
cited under "review of agenda". Anyone who thinks a ticket merits
discussion can say so. Otherwise, once the call concludes, the group has
agreed to the agenda. And once the notes have been out for the better part
of the week and the "any comments on last week's notes?" question in the
following teleconference gets no reply, then the group has agreed and
everyone is party to the decision to close the ticket.
It's still possible to re-open the ticket even after the group has agreed,
provided there's new information that the group didn't consider when they
made the decision. (That is: just coming along later and saying "I wasn't
paying attention when that ticket got closed; I really think one of these
other options that you considered is the right one" isn't cool.)
I hope this explanation addresses the need for...
Laurel will create a ticket for the process of approving terminology; will
hand it off to Philip
--
Dan
--
Ticket URL:
<http://informatics.gpcnetwork.org/trac/Project/ticket/203#comment:1>
gpc-informatics <http://informatics.gpcnetwork.org/>
Greater Plains Network - Informatics
_______________________________________________
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev
