tag:old.nabble.com,2006:forum-1867Nabble - GnuMed2009-11-19T23:11:42ZGnuMed is a group of practising doctors, programmers and free software enthusiasts from around the world, committed to provide a superior, free software solution for community practice. GnuMed home is <a href="http://www.gnumed.org/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26439310Re: clinician input wanted: how to implement "coding"2009-11-19T23:11:42Z2009-11-19T23:11:42ZJim BusserOn 2009-11-18, at 1:07 PM, Karsten Hilbert wrote:
<br><br>> How do you conceptually envision coding to be
<br>> implemented in the client ?
<br>>
<br>> What would you like to use coding *for* ? (I am not asking
<br>> what you *have* to use coding for currently.)
<br>>
<br>> How do you currently use coding ?
<br><br>We only presently use ICD9 for billing. In the billing program that I
<br>wrote, but no longer use, I also used it as the "key" from which to
<br>reference, from a Patient2Diagnoses link table, the reference to the
<br>diagnosis table which had only 2 columns (icd9 and description).
<br><br>> How would you *like* to use coding ?
<br>> Do you see any application of coding ?
<br>> If so, how would you like GNUmed to support that ?
<br><br>I assume the above are closely related :-)
<br><br>What quickly comes to mind...
<br><br>- per patient, a coding system that had a nice population of language
<br>translations could be invaluable, judging from the (at best) limited
<br>translations we achieve when a visiting patient brings a foreign, text-
<br>based document with them. Typically we have no local access to someone
<br>who is both clinically familiar with what might be the patient's true
<br>issue AND confidently able to determine what was meant by the foreign
<br>clinician
<br><br>- per patient, the above even applies to native speakers within the
<br>same language, whose meaning of text-based notes can still be hard to
<br>interpret
<br><br>- per patient, a coding system could offer a semi-automated index of
<br>within-praxis diagnostic certainty (or at least of precision),
<br>depending on the precision that the coding clinician chose to apply,
<br>for example with ICD9 three or four or five character
<br><br>- assisting an organ-based or system-based auto-tree within a
<br>patient's health issues list
<br><br>- reducing small keyboard errors (mistyping words) albeit at the risk
<br>of substituting an item that wildly alters the clinical meaning, based
<br>on mistyping a code character. The UI in this context would take on
<br>critical importance!
<br><br>- across-patient searches and groupings of somewhat-similar conditions
<br><br>- defining potentially-useful language-independent queries that could
<br>be shared among GNUmed users internationally
<br><br>- linking to internal or external clinical guideline engines that will
<br>surely depend on coding systems
<br><br>- transcoding between coding systems, if that proved safely possible
<br><br><br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26439310&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26437368Re: Re: Medication viewing2009-11-19T18:05:08Z2009-11-19T18:05:08ZJim Busser<br>On 2009-11-19, at 11:18 AM, Karsten Hilbert wrote:
<br><br>> Unless the database engine applies an optimizing re-ordering
<br>> to the sequence of actual creation.
<br>>
<br>>> If the list is displayed with its rows sequenced by substance name
<br>>> and within substance name by dosis and within dosis by plan what
<br>>> would you suggest is the grouping that should be offered? By
<br>>> substance?
<br>>
<br>> Yep.
<br><br>If you therefore add as a choice Group by: Substance
<br><br>then the left-most column resulting should be Substance. It would here
<br>be possible to have
<br><br> Substance > Dosis > Handelsname > Plan
<br><br>because in the case of a poly-pill, the dosis refers to the component
<br>while the Plan refers to the poly-pill
<br><br>You could therefore make the argument that under the group order
<br>"Episode" it should be
<br><br> Episode > Substance > Dosis > Handelsname > Plan ...
<br><br>and grouped by Handelsname it should be
<br><br> Handelsname > Plan > Substance > Dosis > ... Episode
<br><br>I am taking pleasure in the suspicion that few EMRs may enjoy this
<br>open dialog, but at least some of the open source ones do :-)
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26437368&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26434505Re: Re: Medication viewing2009-11-19T13:32:14Z2009-11-19T13:32:14ZKarsten HilbertOn Thu, Nov 19, 2009 at 12:16:04PM -0800, Jim Busser wrote:
<br><div class='shrinkable-quote'><br>> >>Therefore maybe there can't be a reliable second-order grouping. I
<br>> >>only continue to feel a tension as to whether to insert the
<br>> >>Handelsname between the left-most column Episode
<br>> >
<br>> >What is left-most depends on the sort order ! ;-)
<br>>
<br>> I meant second-left most, in the case where grouping was by Episode:
<br>>
<br>> Episode Handelsname Substance
<br>>
<br>> otherwise
<br>>
<br>> Handelsname Substance...
<br>>
<br>> ... I do think the latter is better than the alternative
<br>>
<br>> Substance... ... ... ... ... Handelsname
<br>>
<br>> but is that in disagreement?
</div><br>Hm, in the spirit of scientificality (?!) I'd prefer putting
<br>the brand last (except in the brand sorting, of course) but
<br>practical matters probably make your suggestion preferable.
<br>I do appreciate the argument you presented about discussing
<br>medication decisions with the patient.
<br><br>I'll put the brand second-leftmost regardless.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26434505&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26433340Re: Re: Medication viewing2009-11-19T12:16:04Z2009-11-19T12:16:04ZJim Busser<br>On 2009-11-19, at 10:41 AM, Karsten Hilbert wrote:
<br><br>>> Therefore maybe there can't be a reliable second-order grouping. I
<br>>> only continue to feel a tension as to whether to insert the
<br>>> Handelsname between the left-most column Episode
<br>>
<br>> What is left-most depends on the sort order ! ;-)
<br><br>I meant second-left most, in the case where grouping was by Episode:
<br><br> Episode Handelsname Substance
<br><br>otherwise
<br><br> Handelsname Substance...
<br><br>... I do think the latter is better than the alternative
<br><br> Substance... ... ... ... ... Handelsname
<br><br>but is that in disagreement?
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26433340&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26432442Re: Re: Medication viewing2009-11-19T11:18:46Z2009-11-19T11:18:46ZKarsten HilbertOn Thu, Nov 19, 2009 at 08:36:41AM -0800, Jim Busser wrote:
<br><br>> How would rows within columns be understood to be anything other
<br>> than "Sorted" since you presumably apply no random function to
<br>> sequence them?
<br><br>In a relational database rows are by definition stored
<br>unsorted in that at any one time the order rows are returned
<br>is arbitrary unless a specific ordering is explicitely
<br>applied during retrieval.
<br><br>Physical rows can move around on-disk due to several
<br>circumstances: backup/restore, database maintenance,
<br>updating of row values, deletion of other rows, etc.
<br><br>> You either fetch them "unsorted" by sequence of raw
<br>> creation
<br><br>No you can't because of the above. Also, that would NOT be
<br>unsorted - it would be sorted by sequence of creation - as
<br>you correctly point out !
<br><br>>, which is essentially sorted by datetime
<br><br>Unless the database engine applies an optimizing re-ordering
<br>to the sequence of actual creation.
<br><br>> If the list is displayed with its rows sequenced by substance name
<br>> and within substance name by dosis and within dosis by plan what
<br>> would you suggest is the grouping that should be offered? By
<br>> substance?
<br><br>Yep.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26432442&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26431844Re: GNUmed Release 0.6.rc12009-11-19T10:50:12Z2009-11-19T10:50:12ZKarsten HilbertOn Thu, Nov 19, 2009 at 09:51:18AM -0800, Jim Busser wrote:
<br><div class='shrinkable-quote'><br>> >- within GNUmed
<br>> >- across all clinical tables == across all narrative
<br>> >
<br>> >- however: across *all* patients
<br>> >
<br>> >Now, this was always possible with an appropriate query
<br>> >using the report plugin but now it's end-user friendly:
<br>> >
<br>> >There's a widget for entering the search term and the
<br>> >results will be nicely presented in a list from which one of
<br>> >the matching patients can be activated.
<br>>
<br>> Is it a new plug in or was this inserted into an existing plugin?
</div><br>It's being invoked from the EMR menu. The result list is a
<br>popup.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26431844&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26431728Re: Re: Medication viewing2009-11-19T10:41:26Z2009-11-19T10:41:26ZKarsten HilbertOn Thu, Nov 19, 2009 at 09:07:57AM -0800, Jim Busser wrote:
<br><br>> Maybe not. When Episode is the Grouping term is the first order sort
<br>> now determined "invisibly" by whatever was the default or manually-
<br>> determined order of the health issues, and so it is coincidental, or
<br>> for other reasons, that "abdominal pain" appears first, and not
<br>> because of its alpha "a"?
<br><br>Indeed. The order is currently rather arbitrary: it is by
<br>pk_health_issue and thus resulting in a grouping rather than
<br>sorting per se. Then, within the grouping by
<br>pk_health_issue, an alpha sort is applied to the episode
<br>name. "abdominal pain" appears first courtesy of
<br>pk_health_issue being NULL or the lowest in the list and
<br>then it being the first (and only) episode in that group.
<br><br>> Or is the sort order in fact determined by
<br>> this alpha but only in the case of this initial piece of the chain,
<br>> after which the sequence chains to other medications (or non-
<br>> medications) that associate with that same episode etc
<br><br>Sure:
<br><br> self.__map_grouping2order_by_clauses = {
<br> u'episode': u'pk_health_issue, episode, substance, started',
<br> u'brand': u'brand, substance, started'
<br> }
<br><br>So, numerically by pk_health_issue (== grouping with no
<br>obvious order as far as humans are concerned), then
<br>alphabetically by episode (within the health issue), then
<br>alpha by substance, then chrono by .started.
<br><br>> If it is first by undisplayed Health Issue sort, then I imagine what
<br>> we should see is the Unattributed episodes presented together...
<br><br>They are, courtesy of their pk_health_issue being NULL (two
<br>of which do not compare equal but surely don't compare equal
<br>to any non-null pk_health_issue either and thus group
<br>together ;-)
<br><br>> would these be by alpha of the episode name, or by chronologic order
<br>> of the episode start?
<br><br>by alpha of episode name (just as within any other health
<br>issue sub group)
<br><br>> Might it make sense to present the above grouped at the top of the
<br>> list (like in the health issues list)?
<br><br>They do, I believe. However, I've made this explicit now:
<br><br> u'episode': u'pk_health_issue nulls first, episode, substance, started',
<br> u'brand': u'brand nulls last, substance, started'
<br><br>> >>So when the user clicks "Group by Handelsname" can the control cause
<br>> >>Handelsname to be the left-most column,
<br>> >
<br>> >Done. Episode is then put back to the right.
<br>>
<br>> I am just wondering whether we ever want the components of
<br>> multi-part drug to be separated and non-contiguous in a list.
<br><br>Sure, think of the poly-pill where each component can relate
<br>to another episode.
<br><br>> For a moment I wondered whether grouping by Episode should include a
<br>> second-order grouping within Handelname except I suppose
<br>>
<br>> 1) a patient could have received two components each (originally) as
<br>> individual drugs for separate conditions but then (for convenience)
<br>> be prescribed a combined medication. In this case you can't group
<br>> except by breaking the the first.
<br><br>Even if two components are combined into a multi-component
<br>brand they still allowing linking to a different episode
<br>each - even now :-)
<br><br>> 2) one medication can treat two conditions and this becomes even
<br>> more possible with a multi-part drug enabling a tactical choice
<br>> (less available with a single medication) to let another condition
<br>> be shown associated in the table.
<br><br>The backend already has provisions for that
<br>(multi-indication per component) but we don't yet transport
<br>that into the frontend.
<br><br>> Therefore maybe there can't be a reliable second-order grouping. I
<br>> only continue to feel a tension as to whether to insert the
<br>> Handelsname between the left-most column Episode
<br><br>What is left-most depends on the sort order ! ;-)
<br><div class='shrinkable-quote'><br>> >>and within
<br>> >>Stoff by decreasing numeric value of dosis (since a sequence of
<br>> >>presentation of 100 + 50 would be more natural to add than 50 + 100)
<br>> >
<br>> >Oh, OK. Now, since strength isn't numeric in the backend
<br>> >that'd be rather hard. I have added a third-order sort
<br>> >argument of .started, however, which achieves about the same
<br>> >effect.
<br>>
<br>> I am realizing these two strengths could have been registered within
<br>> a single encounter in either order giving unpredictable result via
<br>> above
</div><br>Well, not unpredictable and even influencable (though not
<br>without a bit of effort). It doesn't matter that they were
<br>registered within the same encounter. The row, and
<br>particularly the clin_when thereof, will be of (if slightly)
<br>different values.
<br><br>> but as the strength's non-numeric maybe not bother.
<br><br>Not now, anyways :-)
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26431728&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26430907Re: GNUmed Release 0.6.rc12009-11-19T09:51:18Z2009-11-19T09:51:18ZJim Busser<br>On 2009-11-19, at 9:33 AM, Karsten Hilbert wrote:
<br><div class='shrinkable-quote'><br>> - within GNUmed
<br>> - across all clinical tables == across all narrative
<br>>
<br>> - however: across *all* patients
<br>>
<br>> Now, this was always possible with an appropriate query
<br>> using the report plugin but now it's end-user friendly:
<br>>
<br>> There's a widget for entering the search term and the
<br>> results will be nicely presented in a list from which one of
<br>> the matching patients can be activated.
</div><br>Is it a new plug in or was this inserted into an existing plugin?
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26430907&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26430758Re: GNUmed Release 0.6.rc12009-11-19T09:33:08Z2009-11-19T09:33:08ZKarsten HilbertOn Thu, Nov 19, 2009 at 09:10:08AM -0800, Jim Busser wrote:
<br><br>> >- can do end user friendly free-text search across all EMRs
<br>>
<br>> do you mean within GNUmed, across all clinical tables, on a per
<br>> patient basis or do you mean something else?
<br><br>- within GNUmed
<br>- across all clinical tables == across all narrative
<br><br>- however: across *all* patients
<br><br>Now, this was always possible with an appropriate query
<br>using the report plugin but now it's end-user friendly:
<br><br>There's a widget for entering the search term and the
<br>results will be nicely presented in a list from which one of
<br>the matching patients can be activated.
<br><br>This was a user request ;-)
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26430758&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26430459Re: GNUmed Release 0.6.rc12009-11-19T09:10:08Z2009-11-19T09:10:08ZJim Busserwonderful
<br><br>On 2009-11-19, at 8:13 AM, Karsten Hilbert wrote:
<br><br>> - can do end user friendly free-text search across all EMRs
<br><br>do you mean within GNUmed, across all clinical tables, on a per
<br>patient basis or do you mean something else?
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26430459&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26430431Re: Re: Medication viewing2009-11-19T09:07:57Z2009-11-19T09:07:57ZJim Busser<br>> I agree. It now does.
<br>>
<br>>> --- or did you intend the Episode name actually
<br>>> be the Health issue except for Unattributed and only when
<br>>> unattributed to show the episode name?
<br>>
<br>> No, but would that be preferrable ?
<br><br>Maybe not. When Episode is the Grouping term is the first order sort
<br>now determined "invisibly" by whatever was the default or manually-
<br>determined order of the health issues, and so it is coincidental, or
<br>for other reasons, that "abdominal pain" appears first, and not
<br>because of its alpha "a"? Or is the sort order in fact determined by
<br>this alpha but only in the case of this initial piece of the chain,
<br>after which the sequence chains to other medications (or non-
<br>medications) that associate with that same episode etc
<br><br>If it is first by undisplayed Health Issue sort, then I imagine what
<br>we should see is the Unattributed episodes presented together... would
<br>these be by alpha of the episode name, or by chronologic order of the
<br>episode start?
<br><br>Might it make sense to present the above grouped at the top of the
<br>list (like in the health issues list)?
<br><br>>> So when the user clicks "Group by Handelsname" can the control cause
<br>>> Handelsname to be the left-most column,
<br>>
<br>> Done. Episode is then put back to the right.
<br><br>I am just wondering whether we ever want the components of multi-part
<br>drug to be separated and non-contiguous in a list.
<br><br>For a moment I wondered whether grouping by Episode should include a
<br>second-order grouping within Handelname except I suppose
<br><br>1) a patient could have received two components each (originally) as
<br>individual drugs for separate conditions but then (for convenience) be
<br>prescribed a combined medication. In this case you can't group except
<br>by breaking the the first.
<br><br>2) one medication can treat two conditions and this becomes even more
<br>possible with a multi-part drug enabling a tactical choice (less
<br>available with a single medication) to let another condition be shown
<br>associated in the table.
<br><br>Therefore maybe there can't be a reliable second-order grouping. I
<br>only continue to feel a tension as to whether to insert the
<br>Handelsname between the left-most column Episode and the Substance
<br>because in most cases the elements will in fact be sequenced adjacent,
<br>and because when reviewing with the patient they often recognize the
<br>Handelsname not the substance and to me it would align more naturally
<br>in the patient per-problem discussion where we need them to understand
<br>which drug we're talking about.
<br><br>>> and within
<br>>> Stoff by decreasing numeric value of dosis (since a sequence of
<br>>> presentation of 100 + 50 would be more natural to add than 50 + 100)
<br>>
<br>> Oh, OK. Now, since strength isn't numeric in the backend
<br>> that'd be rather hard. I have added a third-order sort
<br>> argument of .started, however, which achieves about the same
<br>> effect.
<br><br>I am realizing these two strengths could have been registered within a
<br>single encounter in either order giving unpredictable result via above
<br>but as the strength's non-numeric maybe not bother.
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26430431&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26429901Re: Re: Medication viewing2009-11-19T08:36:41Z2009-11-19T08:36:41ZJim BusserOn 2009-11-19, at 5:11 AM, Karsten Hilbert wrote:
<br><div class='shrinkable-quote'><br>>> Can there be a Grouping = none and what would be the best resulting
<br>>> sort... alpha on Stoff (and within Stoff by decreasing numeric value
<br>>> of Dosis)
<br>>
<br>> :-))
<br>>
<br>> You are saying you want Grouping = None and then define a grouping ?
<br>>
<br>> (Note that we've been ungainly mixing grouping and sorting
<br>> in the above discussion.)
</div><br>I presume the above is ;-)
<br><br>Grouping need not be a "special sort" in which – among items that are
<br>identical on an attribute – the sort function essentially does not
<br>apply or, if applied, makes no difference. It is also possible to
<br>group things based on a property that links indirectly to the one
<br>under consideration and may be a non-linear property.
<br><br>How would rows within columns be understood to be anything other than
<br>"Sorted" since you presumably apply no random function to sequence
<br>them? You either fetch them "unsorted" by sequence of raw creation,
<br>which is essentially sorted by datetime, but as it is possible to
<br>backdate when the patient started on a medication, the underlying sort
<br>on creation will be inapparent.
<br><br>Accordingly (apparently) "Unsorted" can mean sequenced on a random
<br>value, or just sorted on a property whose value is not displayed.
<br><br>Ungrouped may therefore mean clustered according to a random property,
<br>or just grouped on a property whose value is not displayed.
<br><br>If the list is displayed with its rows sequenced by substance name and
<br>within substance name by dosis and within dosis by plan what would you
<br>suggest is the grouping that should be offered? By substance?
<br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26429901&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26429673GNUmed Release 0.6.rc12009-11-19T08:13:45Z2009-11-19T08:13:45ZKarsten HilbertI am happy to announce the first 0.6 test release of GNUmed.
<br><br>In the past (regarding 0.5) we've had good success with
<br>releasing early release candidates which offer a good
<br>measure of new functionality including most of the new core
<br>features but aren't necessarily finished products yet.
<br>People started testing and provided valuable feedback such
<br>that 0.5 proper had surprisingly few noticeable bugs.
<br><br>Also, now is your time to speak up about what you think
<br>still needs to be done before release (as in MUST).
<br><br>So here it is:
<br><br> <a href="http://www.gnumed.de/downloads/client/0.6/" target="_top" rel="nofollow">http://www.gnumed.de/downloads/client/0.6/</a><br> <a href="http://www.gnumed.de/downloads/server/v12/" target="_top" rel="nofollow">http://www.gnumed.de/downloads/server/v12/</a><br><br>This will help:
<br><br> <a href="http://www.gnumed.de/downloads/client/gm-install_client_locally.sh" target="_top" rel="nofollow">http://www.gnumed.de/downloads/client/gm-install_client_locally.sh</a><br><br>Changelog:
<br><br>- can promote an episode to being a health issue
<br>- can track diagnostic certainty classification (ABCD) on episodes and issues
<br>- can track procedures performed on a patient
<br>- can do end user friendly free-text search across all EMRs
<br>- can move all progress notes of a pre-selected list of encounters to another episode
<br>- can manage provinces
<br>- can manage substance intake
<br>- can interface with German "MMI/Gelbe Liste" external drug database
<br>- can map gender to replacement placeholder
<br><br>- has more placeholders
<br><br>Sort-of-TODO:
<br><br>- finish up medication handling
<br><br>- home phone/external ID in new patient creator dlg
<br>- add "[] show-all-issues" to soap entry plugin
<br><br>- allow nullifying street comment in demographics plugin
<br>- edit demographics: allow to remove DOB
<br><br><br>So, please download, install, crash, report and enjoy !
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26429673&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26427816medication screenshot, again2009-11-19T06:41:58Z2009-11-19T06:41:58ZKarsten HilbertAttached.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br /> <br /> <br />_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26427816&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>gnumed-screenshot-2009-11-19_15-38-50.png</strong> (97K) <a href="http://old.nabble.com/attachment/26427816/0/gnumed-screenshot-2009-11-19_15-38-50.png" target="_top">Download Attachment</a><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>gnumed-screenshot-2009-11-19_15-40-59.png</strong> (96K) <a href="http://old.nabble.com/attachment/26427816/1/gnumed-screenshot-2009-11-19_15-40-59.png" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26426292Re: Re: Medication viewing2009-11-19T05:25:17Z2009-11-19T05:25:17ZKarsten HilbertOn Thu, Nov 19, 2009 at 12:18:05AM -0800, Jim Busser wrote:
<br><br>> I am tempted to suggest:
<br>>
<br>> 1) reverse the position of the checkbox filter items Unapproved and
<br>> Inactive
<br>>
<br>> --> Inactive, Unapproved
<br><br>Done.
<br><br>> 2) relocate the narrow Unapproved column to become the rightmost of
<br>> the columns. This way, if it is toggled on or off, this would show
<br>> or hide only the right-most column.
<br><br>Done. Note that this does not simply toggle the column
<br>display but actually includes/excludes substance intake
<br>entries based on their approval status.
<br><br>The underlying intent/reasoning behind this approval
<br>business is that this table is going to be used for *all
<br>kinds* of substance use -- including i.v. drug (ab)use,
<br>smoking, alcohol, you name it.
<br><br>> I am not fully sure how the clinician behaviour is helped by the
<br>> presence of this column.
<br><br>It may help inform on whether a particular entry of, say,
<br>cannabis smoking (pain control), alcohol intake (CVD
<br>prevention), or i.v. drug use (Methadon substitution) is
<br>approved of or considered abuse / inappropriate /
<br>unapproved. It helps documenting whether a patient is
<br>taking NSAIDs for regular pain control despite her doctor
<br>doesn't approve of that because of known GIT problems.
<br><br>Or the patient is taking silbutramin weight loss pills which
<br>we don't approve of but must be aware of in hypertension
<br>control.
<br><br>> Presumably there is no intended duration
<br>> (Dauer) and this will be blank and also among the Unapproved will be
<br>> things that worry us, and other things which (although useless) may
<br>> be no health concern. Therefore it is not reliable that missing
<br>> checkmarks need be a reminder to target time to pursue
<br>> discontinuation by the patient.
<br><br>Well, yeah, it'd be the road to madness to try to document
<br>such fine-grained detail in specific fields.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26426292&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26426052Re: Re: Medication viewing2009-11-19T05:11:04Z2009-11-19T05:11:04ZKarsten HilbertOn Wed, Nov 18, 2009 at 11:10:40PM -0800, Jim Busser wrote:
<br><br>> What kind of grouping will Episode achieve?
<br><br>> or ignoring the health issue, since it is not displayed anyway, and
<br>> therefore on
<br>>
<br>> Sort (alpha) on episode name
<br>> Sort (alpha) on Stoff
<br><br>Yes, currently.
<br><br>> Within health issue
<br>> Sort (chrono) on episode start
<br>> Sort (chrono) on begin date
<br>>
<br>> Within health issue
<br>> Sort (alpha) on episode name
<br>> Sort (alpha) on Stoff
<br><br>Both make sense, the first is somewhat more involved. It
<br>also looses the ability to alpha-scan the sub-lists -- which
<br>may or may not be OK ?
<br><br>What certainly makes sense is the sorting by health issue. I
<br>added this now.
<br><br>Row level tooltips will have all the details anyway just
<br>like with measurements.
<br><br>> and can Episode be the (ignoring check-mark) left-most column since
<br>> it is more brain-natural for the sort column(s) to be left-most?
<br><br>Done.
<br><br><br>> I am thinking that when a patient had an episode of hypertension
<br>> that prompted Drug 1, and during a later episode (maybe with a
<br>> different name but still under hypertension) a Drug 2 got added, it
<br>> might be nice that these drugs showed together under the health
<br>> issue Hypertension
<br><br>I agree. It now does.
<br><br>> --- or did you intend the Episode name actually
<br>> be the Health issue except for Unattributed and only when
<br>> unattributed to show the episode name?
<br><br>No, but would that be preferrable ?
<br><br>> The significance of grouping by Handelsname could help to organize:
<br>> - two different strengths of the same manufacturer's product
<br>> - two different substances within a single (combination) product
<br><br>Yes, they would show next to each other in alpha order.
<br><br>> So when the user clicks "Group by Handelsname" can the control cause
<br>> Handelsname to be the left-most column,
<br><br>Done. Episode is then put back to the right.
<br><br>> and would it be an
<br>> alpha-sort on Handelsname and within Handelsname on Stoff
<br><br>Yes.
<br><br>> and within
<br>> Stoff by decreasing numeric value of dosis (since a sequence of
<br>> presentation of 100 + 50 would be more natural to add than 50 + 100)
<br><br>Oh, OK. Now, since strength isn't numeric in the backend
<br>that'd be rather hard. I have added a third-order sort
<br>argument of .started, however, which achieves about the same
<br>effect.
<br><br>> Can there be a Grouping = none and what would be the best resulting
<br>> sort... alpha on Stoff (and within Stoff by decreasing numeric value
<br>> of Dosis)
<br><br>:-))
<br><br>You are saying you want Grouping = None and then define a grouping ?
<br><br>(Note that we've been ungainly mixing grouping and sorting
<br>in the above discussion.)
<br><br>> What is the significance of the left-most check-mark column
<br><br>Now right-most.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26426052&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26425387Re: Medication creation requirements2009-11-19T04:29:10Z2009-11-19T04:29:10ZKarsten HilbertOn Wed, Nov 18, 2009 at 11:54:57PM -0800, Jim Busser wrote:
<br><br>> - doctors need not always provide (or even know) the possible
<br>> proprietary (brand or Handel) names of medications and therefore
<br>> when inputting a medication name it must be possible to create a
<br>> substance name while leaving blank (null) the Handelname
<br><br>Absolutely. This already works. What doesn't work yet is the
<br>other way round - when they actually do know the brand :-)
<br><div class='shrinkable-quote'><br>> - this means that when selecting a substance name it should be
<br>> possible for the doctor to
<br>>
<br>> - be given a list of matches for a substance name
<br>> - and for each substance name, to be offered multiple matching
<br>> Handelnames where these do already exist in the backend
<br>> - where a combination of a substance name with a Handelname is
<br>> desired, select it
<br>> - be able to accept a substance name without having to accept a
<br>> Handelname
<br>> - when a substance name already existed but a suitable matching
<br>> Handelname did not, add the Handelname
<br>>
<br>> - when a substance is one of multiple substances within a
<br>> Handelname that is to be created, be provided some way to enter /
<br>> associate the other components with this Handelname
</div><br>All this is useful and planned. Probably not all of it in
<br>0.6 though which will allow all of the above combinations
<br>but not necessarily *help* with all of them as much as would
<br>be possible.
<br><br>> I am further wondering:
<br>>
<br>> - when the substance is matched, it is returned with a set of
<br>> strengths known to exist for that substance and does the user then
<br>> get to select whichever is the best line from among multiple lines
<br>> each of which offers a different combination of substance with
<br>> strength?
<br><br>Strength will be a phrasewheel returning matches based on
<br>previous use of that substance but allowing another
<br>strength, too, yes.
<br><div class='shrinkable-quote'><br>> - will the user also select from among existing "plans" like 1-0-0-0
<br>> where keyboard input of 1 will filter out 0 and 2 and further
<br>> keyboard input of -0 will filter the choices to the matching
<br>>
<br>> 1-0-0-0
<br>> 1-0-1-0
<br>> 1-0-0-0
<br>> 1-0-0-1
<br>> 1-0-1-1
<br>>
<br>> and any other additional matches from what might exist in the backend?
</div><br>Yes, absolutely.
<br><br>> - should the user be provided two different fields, one for
<br>> substance and another for Handelname
<br><br>Yep, I am working on that right now :-)
<br><br>> and will the choice determine the widget behaviour
<br><br>yes
<br><br>> or will the field serve as a combo box (like
<br>> the name field in which one can put in a name or other identifier)?
<br><br>I thought about that but wasn't sure I can get it to work
<br>predictably and sanely.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26425387&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26422340Re: Re: Medication viewing2009-11-19T00:18:05Z2009-11-19T00:18:05ZJim BusserOn 2009-11-19, at 12:01 AM, Jim Busser wrote:
<br><br>>> What is the significance of the left-most check-mark column
<br><br>On further thinking, this check-mark column is relevant to:
<br><br>- what the patient may be receiving from some other provider which you
<br>do not want to mark yourself as approving
<br><br>- what you may desire the patient to consume less of, or to stop
<br>consuming totally
<br><br>and yet, you may still be in the position to need to prescribe this
<br>substance to the patient, because to refuse might put them in some
<br>danger. For example you may be waiting more collateral documentation
<br>about the true need, or you may be weaning down the dosage on some drug.
<br><br>I am tempted to suggest:
<br><br>1) reverse the position of the checkbox filter items Unapproved and
<br>Inactive
<br><br> --> Inactive, Unapproved
<br><br>2) relocate the narrow Unapproved column to become the rightmost of
<br>the columns. This way, if it is toggled on or off, this would show or
<br>hide only the right-most column.
<br><br>I am not fully sure how the clinician behaviour is helped by the
<br>presence of this column. Presumably there is no intended duration
<br>(Dauer) and this will be blank and also among the Unapproved will be
<br>things that worry us, and other things which (although useless) may be
<br>no health concern. Therefore it is not reliable that missing
<br>checkmarks need be a reminder to target time to pursue discontinuation
<br>by the patient.
<br><br><br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26422340&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26422128Re: Re: Medication viewing2009-11-19T00:01:01Z2009-11-19T00:01:01ZJim BusserOn 2009-11-18, at 11:10 PM, Jim Busser wrote:
<br><br>> What is the significance of the left-most check-mark column, is this
<br>> "Active" or is it Approved? If it is "Active" then how is "Approved"
<br>> visually communicated?
<br><br>Sorry, I missed that you did already just answer this as
<br><br>> approved ones are signalled with the checkmark
<br><br>> inactive substance intake entries are shown in grey
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26422128&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26422010Medication creation requirements2009-11-18T23:54:57Z2009-11-18T23:54:57ZJim BusserJust some things I have been thinking about....
<br><br>- doctors need not always provide (or even know) the possible
<br>proprietary (brand or Handel) names of medications and therefore when
<br>inputting a medication name it must be possible to create a substance
<br>name while leaving blank (null) the Handelname
<br><br>- when selecting a substance name it is possible that the doctor may
<br>know the Handelname when the substance is either uniquely available
<br>only under a single Handelname or because the doctor is specifying the
<br>desired Handelname or because we might not here be talking about a
<br>prescription but may instead be talking about documenting a known
<br>substance already being taken by this patient who is providing both
<br>the substance and the Handelname information
<br><br>- this means that when selecting a substance name it should be
<br>possible for the doctor to
<br><br> - be given a list of matches for a substance name
<br> - and for each substance name, to be offered multiple matching
<br>Handelnames where these do already exist in the backend
<br> - where a combination of a substance name with a Handelname is
<br>desired, select it
<br> - be able to accept a substance name without having to accept a
<br>Handelname
<br> - when a substance name already existed but a suitable matching
<br>Handelname did not, add the Handelname
<br><br> - when a substance is one of multiple substances within a Handelname
<br>that is to be created, be provided some way to enter / associate the
<br>other components with this Handelname
<br><br>I am further wondering:
<br><br>- when the substance is matched, it is returned with a set of
<br>strengths known to exist for that substance and does the user then get
<br>to select whichever is the best line from among multiple lines each of
<br>which offers a different combination of substance with strength?
<br><br>- will the user also select from among existing "plans" like 1-0-0-0
<br>where keyboard input of 1 will filter out 0 and 2 and further keyboard
<br>input of -0 will filter the choices to the matching
<br><br> 1-0-0-0
<br> 1-0-1-0
<br> 1-0-0-0
<br> 1-0-0-1
<br> 1-0-1-1
<br><br>and any other additional matches from what might exist in the backend?
<br><br>- should the user be provided two different fields, one for substance
<br>and another for Handelname and will the choice determine the widget
<br>behaviour or will the field serve as a combo box (like the name field
<br>in which one can put in a name or other identifier)?
<br><br><br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26422010&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26421628Re: Re: Medication viewing2009-11-18T23:10:40Z2009-11-18T23:10:40ZJim BusserWhat kind of grouping will Episode achieve?
<br><br> Within health issue
<br> Sort (chrono) on episode start
<br> Sort (chrono) on begin date
<br><br> Within health issue
<br> Sort (alpha) on episode name
<br> Sort (alpha) on Stoff
<br><br>or ignoring the health issue, since it is not displayed anyway, and
<br>therefore on
<br><br> Sort (alpha) on episode name
<br> Sort (alpha) on Stoff
<br><br>and can Episode be the (ignoring check-mark) left-most column since it
<br>is more brain-natural for the sort column(s) to be left-most?
<br><br><br>I am thinking that when a patient had an episode of hypertension that
<br>prompted Drug 1, and during a later episode (maybe with a different
<br>name but still under hypertension) a Drug 2 got added, it might be
<br>nice that these drugs showed together under the health issue
<br>Hypertension --- or did you intend the Episode name actually be the
<br>Health issue except for Unattributed and only when unattributed to
<br>show the episode name?
<br><br><br>The significance of grouping by Handelsname could help to organize:
<br> - two different strengths of the same manufacturer's product
<br> - two different substances within a single (combination) product
<br><br><br>So when the user clicks "Group by Handelsname" can the control cause
<br>Handelsname to be the left-most column, and would it be an alpha-sort
<br>on Handelsname and within Handelsname on Stoff and within Stoff by
<br>decreasing numeric value of dosis (since a sequence of presentation of
<br>100 + 50 would be more natural to add than 50 + 100)
<br><br><br>Can there be a Grouping = none and what would be the best resulting
<br>sort... alpha on Stoff (and within Stoff by decreasing numeric value
<br>of Dosis)
<br><br><br>What is the significance of the left-most check-mark column, is this
<br>"Active" or is it Approved? If it is "Active" then how is "Approved"
<br>visually communicated?
<br><br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26421628&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26417609Re: Re: Medication viewing2009-11-18T15:15:26Z2009-11-18T15:15:26ZKarsten HilbertOn Thu, Nov 19, 2009 at 12:09:03AM +0100, Karsten Hilbert wrote:
<br><br>> > The medication list can filter on is_currently_active and
<br>> > intake_is_approved_of
<br>>
<br>> 1) Currently inactive substance intake entries are shown in grey.
<br>>
<br>> 2) IF both approved and unapproved substance intake entries
<br>> are shown the approved ones are signalled with the checkmark
<br>> symbol in the first column. Unfortunately, unicode does not
<br>> have thumb-up vs thumb-down codepoints :-(
<br><br>Like so (attached).
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br /> <br />_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26417609&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>gnumed-screenshot-2009-11-19_00-13-49.png</strong> (93K) <a href="http://old.nabble.com/attachment/26417609/0/gnumed-screenshot-2009-11-19_00-13-49.png" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26417524Re: Re: Medication viewing2009-11-18T15:09:03Z2009-11-18T15:09:03ZKarsten HilbertOn Wed, Nov 18, 2009 at 11:50:16PM +0100, Karsten Hilbert wrote:
<br><br>> The medication list can filter on is_currently_active and
<br>> intake_is_approved_of
<br><br>1) Currently inactive substance intake entries are shown in grey.
<br><br>2) IF both approved and unapproved substance intake entries
<br> are shown the approved ones are signalled with the checkmark
<br> symbol in the first column. Unfortunately, unicode does not
<br> have thumb-up vs thumb-down codepoints :-(
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26417524&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26417245Re: Re: Medication viewing2009-11-18T14:50:16Z2009-11-18T14:50:16ZKarsten HilbertOn Fri, Oct 30, 2009 at 09:47:07AM -0700, Jim Busser wrote:
<br><br>> So even though we do not yet (compared to problem list) support
<br>> user-defined sorting,
<br><br>Oh, we now do have two sort/group modes:
<br><br> - by episode, then by substance name
<br> - by brand name, the by substance name
<br><br>This corresponds to what we've been documenting on the
<br>relevant wiki page.
<br><br>> Looking over the original suggestion (below), any medications which
<br>> patients have been advised to take in future *if needed* could as
<br>> you say have a future clin_when. If you think about it, this could
<br>> be infinity for a substance that did not need a prescription,
<br>> whereas in my province a prescription is only valid for 1 year
<br>> (narcotics less) so that could eventually be supplied by a
<br>> rules-aware prescribing widget.
<br><br>This is actually an idea I like much more then clin_when
<br>being NULL.
<br><div class='shrinkable-quote'><br>> Future maybe-meds should perhaps be split out of A to become the new
<br>> group B (clin_when+duration > today) making the shown B and C into C
<br>> and D respectively
<br>>
<br>> Can wx allow row colours based on values?
<br>>
<br>> Suggest to filter / sort:
<br>>
<br>> "Group A" = current (blue) = "soft_stop_date" is {NULL or future-
<br>> dated} and hard_stop_date is NULL
<br>> "Group B" = undefined (orange) = "soft_stop_date" is today-or-past-
<br>> dated} and hard_stop_date is NULL
<br>> "Group C" = stopped (grey) = hard_stop_date is not NULL (NULL not >
<br>> today)
</div><br>The medication list can filter on is_currently_active and
<br>intake_is_approved_of
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26417245&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26416865Re: Re: Medication viewing2009-11-18T14:22:51Z2009-11-18T14:22:51ZKarsten HilbertOn Thu, Oct 29, 2009 at 06:01:07PM -0700, Jim Busser wrote:
<br><div class='shrinkable-quote'><br>> Made me think of a wrinkle surrounding "when was the medication
<br>> started" (.clin_when) ...
<br>>
<br>> Suppose I provide a prescription, instructing the patient as follows:
<br>>
<br>> - if the current symptoms do not improve by X days
<br>> - if in future you should develop
<br>> - symptoms of H1N1
<br>> - an exacerbation of COPD
<br>> - a flare-up of gout
<br>>
<br>> you should being taking
<br>> - oseltamivir x 5 days
<br>> - doxycycline x 5 days
<br>> - colchicine x 3 days
<br>>
<br>> So maybe in this case it is important to not forget that this
<br>> medication despite that it is not current "at this moment" could
<br>> easily become current at any time after the visit has ended. So I am
<br>> thinking that maybe in this case
<br>>
<br>> - clin_when could be NULL
<br>> - duration could be a definable interval
</div><br><br><br>> What approach to data creation is taken in GNUmed / Postgres... in
<br>> other words, when in a widget a user would click 'New", is there:
<br>>
<br>> - a row created in a Postgres table that takes on default values
<br>> which are then displayed to the user?
<br><br>No. A new row is only created after the user clicked [Save]
<br>and the data passed the validity tests.
<br><br>> - being not yet committed until after the user clicked "Save", would
<br>> this so-called row be equivalent to a 'virtual" row?
<br><br>It would, yes. In fact, it would be so virtual as to not
<br>exist yet.
<br><br>> - is it known whether the client has the ability to receive schema
<br>> default values
<br><br>The client doesn't but it is possible to get them.
<br><br>> and refresh them based on contextually-available
<br>> information so that without user interaction the user could already
<br>> be presented something closer to what they need?
<br><br>The widgets try to present meaningful defaults if at all.
<br><br>> - if the client would default to offer (as clin_when) the current
<br>> datetime and the user would delete this datetime to make the field
<br>> empty, would this result in the value being saved as NULL?
<br><br>It would if it could. In actuality it would result in the
<br>validity tests failing.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26416865&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26415776clinician input wanted: how to implement "coding"2009-11-18T13:07:45Z2009-11-18T13:07:45ZKarsten HilbertHello all,
<br><br>this is a more general request for input !
<br><br> How do you conceptually envision coding to be
<br> implemented in the client ?
<br><br> What would you like to use coding *for* ? (I am not asking
<br> what you *have* to use coding for currently.)
<br><br> How do you currently use coding ?
<br><br> How would you *like* to use coding ?
<br><br> Do you see any application of coding ?
<br><br> If so, how would you like GNUmed to support that ?
<br><br>Note that none of this will be in 0.6, perhaps not
<br>even in 0.7, or maybe just bits of it.
<br><br>Also note that you don't need to worry about backend tables
<br>here.
<br><br><br>Now, there's your chance ! :-)
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26415776&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26303821linuxtoday.com, again2009-11-11T08:02:26Z2009-11-11T08:02:26ZKarsten HilbertFYI:
<br><br><a href="http://www.ghacks.net/2009/11/10/set-up-a-gnumed-backend-server/" target="_top" rel="nofollow">http://www.ghacks.net/2009/11/10/set-up-a-gnumed-backend-server/</a><br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26303821&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26303059Re: Hook scripts (was Re: CCHIT AM)2009-11-11T06:46:34Z2009-11-11T06:46:34ZKarsten HilbertOn Wed, Nov 11, 2009 at 06:35:58AM -0800, Jim Busser wrote:
<br><div class='shrinkable-quote'><br>> >I would suggest gnumed/client/hookscripts/
<br>> >
<br>> >Note, however, that locally it would need to live under
<br>> >~/.gnumed/scripts/
<br>>
<br>> So... stored/archived, in CVS and in downloaded copies of the client
<br>> under
<br>>
<br>> gnumed/client/hookscripts/
<br>>
<br>> because whether or not they would run is controlled at the level of
<br>> the client,
</div><br>More specifically at the level of the local *user*, yes.
<br><br>> and that control is further determined
<br><br>*only*
<br><br>> at run time by the presence of the script under
<br>>
<br>> ~/.gnumed/scripts/
<br><br>yes
<br><br>> as per
<br>>
<br>> <a href="http://cvs.savannah.gnu.org/viewvc/gnumed/gnumed/client/doc/hook_script_example.py?root=gnumed&view=markup" target="_top" rel="nofollow">http://cvs.savannah.gnu.org/viewvc/gnumed/gnumed/client/doc/hook_script_example.py?root=gnumed&view=markup</a><br><br>yes
<br><br>> ps in the above hook_script_example what would the line do:
<br>> # enc = 'cp850' # FIXME: configurable
<br><br>It defines the encoding to use for that particular GDT
<br>export file.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26303059&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26302903Re: Hook scripts (was Re: CCHIT AM)2009-11-11T06:35:58Z2009-11-11T06:35:58ZJim Busser<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 2009-11-11, at 5:18 AM, Karsten Hilbert wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">I would suggest gnumed/client/hookscripts/<br><br>Note, however, that locally it would need to live under<br>~/.gnumed/scripts/<br></span></blockquote></div><br><div>So... stored/archived, in CVS and in downloaded copies of the client under</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>gnumed/client/hookscripts/</div><div><br></div><div>because whether or not they would run is controlled at the level of the client, and that control is further determined at run time by the presence of the script under</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>~/.gnumed/scripts/</div><div><br></div><div>as per</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> <a href="http://cvs.savannah.gnu.org/viewvc/gnumed/gnumed/client/doc/hook_script_example.py?root=gnumed&view=markup" target="_top" rel="nofollow">http://cvs.savannah.gnu.org/viewvc/gnumed/gnumed/client/doc/hook_script_example.py?root=gnumed&view=markup</a></span></div><div><br></div><div>ps in the above hook_script_example what would the line do:</div><span class="Apple-style-span" style="font-family: Times; "><pre> # enc = 'cp850' # FIXME: configurable<br></pre></span></body></html><br />_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26302903&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26303049Re: CCHIT - access restrictions per SOAP note2009-11-11T06:05:16Z2009-11-11T06:05:16ZKarsten HilbertOn Wed, Nov 11, 2009 at 05:45:48AM -0800, Jim Busser wrote:
<br><br>> >Wouldn't *all* clinical information be confidential from
<br>> >non-clinical users regardless of their is_confidential
<br>> >health issue status ?
<br>>
<br>> Yes, but it appeared in CCHIT that they wanted nurse clinicians to
<br>> be able to access the clinical record without accessing items marked
<br>> is_confidential.
<br><br>"Items" then means "certain SOAP notes" ?
<br><br>> Therefore the question about views remains relevant?
<br><br>That would work, yes.
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26303049&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26302452Re: CCHIT - access restrictions per SOAP note2009-11-11T05:51:56Z2009-11-11T05:51:56ZVerbus CountsAll,<br><br>I think views is the way to go here.<br><br>Verbus<br><br><div class="gmail_quote">On Wed, Nov 11, 2009 at 8:45 AM, Jim Busser <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26302452&i=0" target="_top" rel="nofollow">jbusser@...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
On 2009-11-11, at 4:19 AM, Karsten Hilbert wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Wouldn't *all* clinical information be confidential from<br>
non-clinical users regardless of their is_confidential<br>
health issue status ?<br>
</blockquote>
<br></div>
Yes, but it appeared in CCHIT that they wanted nurse clinicians to be able to access the clinical record without accessing items marked is_confidential.<br>
<br>
Therefore the question about views remains relevant?<div><div></div><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Gnumed-devel mailing list<br>
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26302452&i=1" target="_top" rel="nofollow">Gnumed-devel@...</a><br>
<a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_blank" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br>Verbus M. Counts<br>803-727-8576 <a href="http://palmedtech.com/problems" target="_top" rel="nofollow">http://palmedtech.com/problems</a><br>
<br />_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26302452&i=2" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26301503Re: CCHIT - access restrictions per SOAP note2009-11-11T05:45:48Z2009-11-11T05:45:48ZJim Busser<br>On 2009-11-11, at 4:19 AM, Karsten Hilbert wrote:
<br><br>> Wouldn't *all* clinical information be confidential from
<br>> non-clinical users regardless of their is_confidential
<br>> health issue status ?
<br><br>Yes, but it appeared in CCHIT that they wanted nurse clinicians to be
<br>able to access the clinical record without accessing items marked
<br>is_confidential.
<br><br>Therefore the question about views remains relevant?
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26301503&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26301230Re: Hook scripts (was Re: CCHIT AM)2009-11-11T05:18:57Z2009-11-11T05:18:57ZKarsten HilbertOn Tue, Nov 10, 2009 at 02:38:52PM -0800, Jim Busser wrote:
<br><div class='shrinkable-quote'><br>> >Sure, use a hook script hooking into
<br>> >"post_patient_activation".
<br>>
<br>> If people would develop and contribute hook scripts, where in the
<br>> CVS would we propose that these be stored?
<br>>
<br>> Do we create a new directory "hookscripts" at the same level as
<br>>
<br>> /client
<br>> /server
</div><br>I would suggest gnumed/client/hookscripts/
<br><br>Note, however, that locally it would need to live under
<br>~/.gnumed/scripts/
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26301230&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26300413Re: CCHIT - access restrictions per SOAP note2009-11-11T04:19:30Z2009-11-11T04:19:30ZKarsten HilbertOn Wed, Nov 11, 2009 at 12:06:37AM -0800, Jim Busser wrote:
<div class='shrinkable-quote'><br>> Subject: Re: [Gnumed-devel] CCHIT - access restrictions per SOAP note
<br>> X-Mailer: Apple Mail (2.1076)
<br>>
<br>> On 2009-11-07, at 11:58 AM, Karsten Hilbert wrote:
<br>>
<br>> >This is not easily possible. PostgreSQL so far does not
<br>> >natively support row level access permissions.
<br>>
<br>> Could it manageably be achieved indirectly via Postgres' views in
<br>> which views could include or exclude rows having a specified value?
<br>>
<br>> If yes, then we could have
<br>>
<br>> - nonclinical views that all (including staff) could access
<br>> - clinical views (routine) WHERE clin.health_issue.is_confidential
<br>> IS FALSE
<br>> - clinical views (unrestricted)
</div><br>Wouldn't *all* clinical information be confidential from
<br>non-clinical users regardless of their is_confidential
<br>health issue status ?
<br><br>Karsten
<br>--
<br>GPG key ID E4071346 @ wwwkeys.pgp.net
<br>E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26300413&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>tag:old.nabble.com,2006:post-26297485Re: CCHIT - access restrictions per SOAP note2009-11-11T00:06:37Z2009-11-11T00:06:37ZJim BusserOn 2009-11-07, at 11:58 AM, Karsten Hilbert wrote:
<br><br>> This is not easily possible. PostgreSQL so far does not
<br>> natively support row level access permissions.
<br><br>Could it manageably be achieved indirectly via Postgres' views in
<br>which views could include or exclude rows having a specified value?
<br><br>If yes, then we could have
<br><br>- nonclinical views that all (including staff) could access
<br>- clinical views (routine) WHERE clin.health_issue.is_confidential IS
<br>FALSE
<br>- clinical views (unrestricted)
<br><br><br>_______________________________________________
<br>Gnumed-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26297485&i=0" target="_top" rel="nofollow">Gnumed-devel@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/gnumed-devel" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/gnumed-devel</a><br><p>From forum: <a href="http://old.nabble.com/GnuMed---Dev-f1869.html" embed="fixTarget[1869]" target="_top" >GnuMed - Dev</a></p>