Questions about ^ZJOB on GTM. ??Unexpected behavior??

[Kevin Toppenberg]

I am running GT.M

If I run ^ZJOB against another session that is executing code, then all goes as expected.

But if I do the same when the other session is at a command prompt, I get the following error message issues from the target console window.

%GTM-E-INDEXTRACHARS, Indirection string contains extra trailing characters

                At M source location JOBEXAM+3^ZU

%GTM-E-ZINTDIRECT, Attempt to enter direct mode from $ZINTERRUPT

                At M source location JOBEXAM+3^ZU

I traced through this, and the error occurs at this line:

I %ZPOS["^" S ^XUTL("XUSYS",$J,"codeline")=$T(@%ZPOS)

and %ZPOS value at the time of the error is: +1^GTM$DMOD

It may be that ^ZJOB is not intended to be run against another session that is at the GT.M prompt.  But it seems that this is a minor bug/unexpected state that could be  accounted for.

Kevin

[Kevin Toppenberg]

I changed my line as follow and it seems to solve the problem:

I (%ZPOS["^")&(%ZPOS'["$DMOD") S ^XUTL("XUSYS",$J,"codeline")=$T(@%ZPOS)  ;"//kt

Kevin

[Christopher Edwards]

On Mon, Jan 26, 2015 at 7:59 AM, Kevin Toppenberg <kdt...@gmail.com> wrote:

I changed my line as follow and it seems to solve the problem:

I (%ZPOS["^")&(%ZPOS'["$DMOD") S ^XUTL("XUSYS",$J,"codeline")=$T(@%ZPOS)  ;"//kt

Thank you Kevin for the issue report and probable fix.

I hope you don't mind but when I see these I log them to OSEHRA's open issue tracker and track the attribution to where I found it and any fixes that may be included. The goal is to have these fixes integrated so we don't have to keep re-fixing bugs or hunting them down again.

OSEHRA issue: http://issues.osehra.org/browse/CONV-84

Thanks!

Christopher Edwards
cje...@gmail.com

[Kevin Toppenberg]

Christopher,

Thanks.  That is exactly what was needed. 

Kevin

[Kevin Toppenberg]

While I'm on the topic of ^ZJOB, is there any interest in an API to this functionality?  I need this at my site and I am going to write a (mostly) silent API to get the information programatically.  It will be in the next TMG library, but it is also something that could be formally put into ZJOB if anyone wanted.

Kevin

[Sam Habiel]

Kevin,

Before you start anything, take a look at Lloyd Milligan's excellent
new ZJOB routine.

http://www.seaislandsystems.com/ZSY/SystemStatus.html

I don't use the one that comes with WV anymore.

--Sam

> --
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Hardhats" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hardhats+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Sam Habiel, Pharm.D.
VISTA Expertise Network

PS: If you find anything open source that I do useful to you, consider
buying me a present from my wish list as a token of thanks:
http://www.amazon.com/gp/registry/wishlist/?ie=UTF8&cid=A198EOA15E5N5B

[Sam Habiel]

Correction: s/ZJOB/ZSY/

[Kevin Toppenberg]

This looks OK, but it is still a command-line utility with direct writes to the console (nothing wrong with that, just not an API).  I have already written the wrapper from the WorldVistA version of ZJOB that does what I want.  I need to be able to fetch an array on the variable table from another process programmatically. 

Kevin

[Sam Habiel]

Does ZSHOW "V":"VARNAME" suit you? Also, $ZINT puts the vars in ^XUTL
for the process.

[Kevin Toppenberg]

Sam,

I started another post where I wrote out all my rationale for my course of action.  However, as I did that I realized an easier method of achieving my goal.  I'd be happy to lay it all out some other time. But the short version is that I have cooperation between two processes.  So there is no need for a mupip interrupt to get variables from Process A into Process B.  I can just store in ^XTMP or ^TMG etc.

Thanks,

Kevin

[Andy Bruce]

http://www.cnbc.com/id/102368657

While ir remains to be seen how HHS plans to accomplish this shift
voluntarily...

Writing capitated or bundled reimbursement/management modules should
(sharply) become more important as the cost of incremental support
services (for reimbursement) rise with this announced (and massive)
shift to the "new risk-sharing" model usage. It's also important to
build data (experience) for defensive reporting and actuarial purposes
as historic data stores will represent a barrier to entry into
understanding (calculating and predicting) the "cost of quality" in the
future...think "cost of funds" approach. This means longitudinal studies
and "Spells of Illness" (within pre and post time windows) will be
necessary for both inpatient and outpatient services...which has been
cited as the primary problem by the shared savings program participants
(ACOs) who have exited in the recent past. Deriving a starting point has
been very painful for many early adopters as will operating within
statistical norms for many providers may turn out to be difficult for
high fixed-cost organzations. Data on payment performance (outliers,
pipeline efficiency, etc) and comparative effectiveness (of
quality/safety initiatives) will have to be developed and integrated
into reimbursement as a routine matter of getting paid and corrected in
the cost recapture and opportunity models upon which previous investment
decisions were based...to avoid running blind. Many of the remaining
healthy enterprises could not keep their earnings positive without
blurring the lines between providers and insurers. Such announcements
promise to hasten industry consolidations led by organizations with
expertise in actuarial sciences...and we might do well to acknowledge
this sooner than later. Sounds like the time is upon us. Let's remember
the new risk model levels the playing field for this whole new industry
sector and represents an opportunity similar to meaningful use in the
management and reimbursement side of healthcare informatics.
Just my opinion...you be the judge.

Andy

[Nancy Anthracite]

Very few ACOs have been successful and HHS has had to push full risk sharing
into the future yet HHS is pushing like the theory is fact and going ahead
with this. This reminds me of the previous round of capitation with gate
keepers. I remember well that what happened was that patients had physicians
who would not take care of them or refer them to avoid the costs so they would
not lose with capitation. That was back in the days before they figured out
that patients self referring to specialists was not more costly than having
gate keepers. I can also see in the tea leaves that HHS will eventually
demand that patients cannot not switch physicians to help advance the cause of
ACOs. I am willing to bet a patient will have to pick an ACO and stick with
it like they do an insurance company with only certain times of the year they
can switch.

--
Nancy Anthracite

[Andy Bruce]

Modern Healthcare just issued this news alert:

Wednesday, January 28, 2015

Breaking News

BREAKING: Major providers, insurers unite to shift more business to quality-of-care model
Several of the nation's largest health systems and insurers are joining together in a new task force with the goal of shifting 75% of their business to contracts with incentives for quality and lower-cost healthcare.

I guess this is part of the answer to how this latest brainstorm will be accomplished...the bigger players eat the smaller ones. Consolidation is relatively easy to set up while capital is king...and the scale card is being played. Apparently the players have agreed there's a sweet spot in the stratosphere...but a financial advantage does not equal a service/quality advantage.

I believe I can make a reasonable argument consolidation is not a preferred substitute for a single payer plan. The same fears I voiced about the demise of the distributed rural system can now be applied across the provider spectrum using scale as well as demographic stratification.

There's a long list of known exploits when closing the third party payer gap by merging providers and insurers...and it makes me uncomfortable when the strongest players remaining on the field happen to be Pharma and Insurance.

So brush up your Merger & Acquisition (M&A) position...apparently Anti-trust interpretations are being revisited...and hang a welcome banner for our new overlords.

Just my opinion

Andy

On 1/26/2015 9:46 PM, Nancy Anthracite wrote: