Working for today's Veterans

 

With all of the recent talk about VA’s public media syntax and non-crystal clear comments on their enterprise-wide refactoring strategy, our team just wanted to provide a little clarity about where our contract is headed and what our project team is and will be working on.

In the grand scheme of things for VistA, VA requires that our team work on reorganizing VistA modules into more modular components and with open, standardized interfaces with a three-tier architecture in mind.  Since refactoring all of VistA is a monumental task and not the intended product of our contract, we are starting with one module and seeing what successful methodology and lessons learned can be extracted for future refactoring; if time permits in the contract PoP we will then start the complete cycle of refactoring and certification for another module (currently undeclared).

It is intended that this refactoring will be useful to a developer currently, allowing the simplified code to act as a structured springboard for any future application development (or possible replacement); the code exhibits maximum usefulness for today’s open source EHR developer when used sooner rather than later for a long term (and currently unmapped) goal.

While iEHR is a long term and very important goal, it should be noted that the current refactoring efforts are for VistA alone…unfortunately this presents two valid but completely opposite assumptions: 1) Will VistA undergo replacement with COTS products for certain modules/packages, and 2) Why refactor VistA when iEHR is the suspected future health record application? 

Our project’s refactoring efforts are working with/towards both of those assumptions: while refactoring certain modules can possibly allow for an easy plug-n-play with other efficient developed applications or COTS products, they also allow easier application implementation for whatever the future iEHR plan and goals may be. 

Since this monumental project (iEHR) and its architecture haven’t been finalized, all we can do is work in the now and work to make it easier for open source EHR developers.  Yes, planning for the future is always on our minds, but currently we are focused on making VistA better for today’s Veterans; if today’s changes are used to support future Veterans, then we have successfully completed two objectives.

like0

Comments

Let's not forget that VistA is saving Veterans lives today

Tom Munnecke's picture

I remember riding in the staff elevator at Loma Linda VA medical center.  The door would open, and a gurney covered with a sheet would be pushed in, on its way to the morgue.  This was a very powerful lesson in the critical nature of what hospitals do.  I think it important that people realize that what we are typing on our keyboards today eventually has very realworld life and death consequences.

VistA is saving lives today.  As Trotter and Uhlman explain in Meaningful Use and Beyond:

“years before the healthcare profession as a whole was aware of the dangers of Vioxx, the VA discovered on its own that it was a dangerous medication. Data from the VA’s electronic healthcare record, VistA, had alerted the VA that something was amiss with Vioxx. The VA took steps to ensure that Vioxx was prescribed only with careful monitoring and only in special circumstances, a drug of last resort. By doing so, the VA saved thousands of lives.”

Ross Fletcher MD, Chief of Staff of the Washington VA Medical Center, credits VistA with dramatically improving cardiac health, and introducing an entirely new health care model across the VA in this interview.  

Philip Longman Best Care Anywhere, Why VA Health Care is Better than Yours documents VistA's role in the dramatic organizational transformation of the VA, stimulated in part by VistA.

Nearly every doctor under the age of 45 has used VistA as part of their residency training at a VA hospital, and it enjoys a very positive reputation.  VistA has won numerous medical informatics awards.  

Health IT projects have a long history of spectacular failures: here are some of the recent ones: the UK's National Health Service's $17b writeoff, the US Department of Defense  AHLTA, $4b loss, and the province of Ontario, Canada $1b loss.  

Here are some personal reflections sent to me from an Army physican:

"AHLTA is far worse that you even alluded. It has virtually sucked the life out of our Providers and our MTFs [Medical Treatment Facilities] … Any discussions that CHCS [Composite Health Care System, is a fork of the VistA] Ancillary functions will be replaced by the AHTLA as an architecture are just smoke screens for the embarrassment that AHLTA really is... The worst part of AHLTA is when you actually have to read some of the documentation it generates…. there is rarely a coherent statement in a 3 page clinical note.

 

AHLTA is more than Intolerable…It’s the 3rd highest reason listed by the Army at the June 08 AUSA Conference Providers are leaving the military…

 

A medical flag officer has offered me even stronger comments about how bad AHLTA is, and the detremental effects it has had on the health of our nation's warriors..

It is as if VA has been launching successful Moon shots, and DoD is still struggling to keep its rockets from blowing up on the launch pad.  VistA is saving lives, enjoying great clinical success, and AHLTA is sucking the life out of providers and facilities, and causing physicians to leave military service just when we need them the most.

This cycle has been going on for decades.  Every 8-10 years, someone on The Hill gets upset about it, and huffs and puffs at the secretaries, who pledge to straighten things out, along with a "please send money" request.  Then, things blow up again,  a new set of players move in to change the name of the organization,  blame the technology rather than their management of it, and the cycle repeats.

I see IEHR as just another loop around this cycle.  It seems to me that a simple HHS Direct approach would take care of most of the technical problems, particularly since it is essentially an updated version of the approach I used in the first VA/DoD interface in 1985.  This would offer a loosely-coupled interface, and DoD could continue to try to launch their rockets while VA could do their moonshots and beyond.  

The hallmark of VistA's early success was its intense focus on patients and providers, an evolutionary approach I called "generations, not specifications."  We didn't presume to know the final results when we started, but rather created a "good enough" initial system, followed by a "make it better" process in conjunction with real world users.  Developers  trusted the users to help and guide the development process, who in turn became the champions for the system as it evolved.

I'm glad to see that refactoring is retaining a Veteran focus.  I think we need to keep our focus on what is working in VistA, not just at a technical level, but the clinical processes that have so sucessfully been built on top of it.

I think that we also need to recognize that much, if not most, of the clinical success of VistA has been through its support of the informal processes of health care, cutting across the branches of the organization chart and software packages. 

So, let's keep our focus on the patient, rather than mega-centralized political extravaganzas.

 

like0

Working for today's Veterans

David Mendes's picture

Congratulations for this no-nonsense review that illustrates very simply the reasons of success that VistA enjoyed for so-long.

Yours

David Mendes

De: Apache [mailto:apache@groups.osehra.org] Em nome de Tom Munnecke
Enviada: sábado, 7 de Janeiro de 2012 17:44
Para: EHR Refactoring Services
Assunto: Re: [ehr-refactoring-services] Working for today's Veterans

I remember riding in the staff elevator at Loma Linda VA medical center. The door would open, and a gurney covered with a sheet would be pushed in, on its way to the morgue. This was a very powerful lesson in the critical nature of what hospitals do. I think it important that people realize that what we are typing on our keyboards today eventually has very realworld life and death consequences.

VistA is saving lives today. As Trotter and Uhlman explain in Meaningful Use and Beyond: <http://shop.oreilly.com/product/0636920020110.do>

“years before the healthcare profession as a whole was aware of the dangers of Vioxx, the VA discovered on its own that it was a dangerous medication. Data from the VA’s electronic healthcare record, VistA, had alerted the VA that something was amiss with Vioxx. The VA took steps to ensure that Vioxx was prescribed only with careful monitoring and only in special circumstances, a drug of last resort. By doing so, the VA saved thousands of lives.”

Ross Fletcher MD, Chief of Staff of the Washington VA Medical Center, credits VistA with dramatically improving cardiac health, and introducing an entirely new health care model across the VA in this interview <http://www.youtube.com/watch?v=ai6OgG-wIt4> .

Philip Longman Best Care Anywhere, Why VA Health Care is Better than Yours <http://www.amazon.com/Best-Care-Anywhere-2nd-Health/dp/0982417152> documents VistA's role in the dramatic organizational transformation of the VA, stimulated in part by VistA.

Nearly every doctor under the age of 45 has used VistA as part of their residency training at a VA hospital, and it enjoys a very positive reputation. VistA has won numerous medical informatics awards.

Health IT projects have a long history of spectacular failures: here are some of the recent ones: the UK's National Health Service's $17b writeoff <http://munnecke.com/blog/?p=1073> , the US Department of Defense AHLTA <http://munnecke.com/blog/?p=558> , $4b loss, and the province of Ontario, Canada $1b <http://munnecke.com/blog/?p=1079> loss.

Here are some personal reflections sent to me from an Army physican:

"AHLTA is far worse that you even alluded. It has virtually sucked the life out of our Providers and our MTFs [Medical Treatment Facilities] … Any discussions that CHCS [Composite Health Care System, is a fork of the VistA] Ancillary functions will be replaced by the AHTLA as an architecture are just smoke screens for the embarrassment that AHLTA really is... The worst part of AHLTA is when you actually have to read some of the documentation it generates…. there is rarely a coherent statement in a 3 page clinical note.

AHLTA is more than Intolerable…It’s the 3rd highest reason listed by the Army at the June 08 AUSA Conference Providers are leaving the military…

A medical flag officer has offered me even stronger comments about how bad AHLTA is, and the detremental effects it has had on the health of our nation's warriors..

It is as if VA has been launching successful Moon shots, and DoD is still struggling to keep its rockets from blowing up on the launch pad. VistA is saving lives, enjoying great clinical success, and AHLTA is sucking the life out of providers and facilities, and causing physicians to leave military service just when we need them the most.

This cycle has been going on for decades. Every 8-10 years, someone on The Hill gets upset about it, and huffs and puffs at the secretaries, who pledge to straighten things out, along with a "please send money" request. Then, things blow up again, a new set of players move in to change the name of the organization, blame the technology rather than their management of it, and the cycle repeats.

I see IEHR as just another loop around this cycle. It seems to me that a simple HHS Direct approach <http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__dir... would take care of most of the technical problems, particularly since it is essentially an updated version of the approach I used in the first VA/DoD interface in 1985 <http://www.flickr.com/photos/munnecket/143879841/> . This would offer a loosely-coupled interface, and DoD could continue to try to launch their rockets while VA could do their moonshots and beyond.

The hallmark of VistA's early success was its intense focus on patients and providers, an evolutionary approach I called "generations, not specifications." We didn't presume to know the final results when we started, but rather created a "good enough" initial system, followed by a "make it better" process in conjunction with real world users. Developers trusted the users to help and guide the development process, who in turn became the champions for the system as it evolved.

I'm glad to see that refactoring is retaining a Veteran focus. I think we need to keep our focus on what is working in VistA, not just at a technical level, but the clinical processes that have so sucessfully been built on top of it.

I think that we also need to recognize that much, if not most, of the clinical success of VistA has been through its support of the informal processes of health care, cutting across the branches of the organization chart and software packages.

So, let's keep our focus on the patient, rather than mega-centralized political extravaganzas.

--
Full post: http://www.osehra.org/blog/working-todays-veterans
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/433

like0

Refactoring

Art Hamerschlag's picture

This is a very helpful and informative discussion!  I have a very basic question.  You say above that "In the grand scheme of things for VistA, VA requires that our team work on reorganizing VistA modules into more modular components and with open, standardized interfaces with a three-tier architecture in mind."  Excellent!  But you do not say that part of the refactoring will be to incorporate the use of an open source Business Rules Engine, an open source Work Flow Engine, and table driven architecture.  My understanding  is that by using these tools, the 20 million lines of VistA code could be collapsed to 5 million or fewer, and maitenance would be much simnpler, faster and cheaper.  Will refactoring incorporate these tools and significantly reduce the lines of code?    

like0

Refactoring

Afsin Ustundag's picture

No.  This is, at least for now, is a Mumps only project.  We will try to make business rules more readible in the code so this project can be a step to incorporate open source Business Rules Engines.

 

 

 

 

like0

How about a Prime Directive that the new system saves lives?

Tom Munnecke's picture

Art said, "But you do not say that part of the refactoring will be to incorporate the use of an open source Business Rules Engine, an open source Work Flow Engine, and table driven architecture.  My understanding  is that by using these tools, the 20 million lines of VistA code could be collapsed to 5 million or fewer, and maitenance would be much simnpler, faster and cheaper.  Will refactoring incorporate these tools and significantly reduce the lines of code?"

I'd like to hear more about these tools... I had done some work on a Rules Engine in VistA, called RuleMan, that extended the semantics of the data dictionary, and went to a Drools http://www.jboss.org/drools Bootcamp last year and some some potential - as well as great complexity.

I agree that workflow is a critical component to all this, particularly after all the state information has been stripped out of the rat's-nests of interfaces and standards I see being banded about.  Stateless protocols are wonderful for certain things, but at the same time, health care is one of the most stateful activities we face in society today. 

Managing the state of objects in a complex system of this size is going to be an enormous challenge.  Transactional systems have the weakness that it is difficult to to deal with things that don't trigger a transaction.  It's pretty easy to figure out what to do with a lab test message.  Discovering that a lab test wasn't ordered, or was ordered and wasn't delivered/read/considered is a whole 'nuther problem.

But the things that DON'T happen in health care in a system can be the most important.  I was scheming a system I called PENDEX (Pending Index) - that would provide a way of posting expectations, and working back from them.

But that was all in the olden days, when I had a single semantic domain to describe just about everything in the clinical setting, focused intensely on the patient, controlled by a single language with 19 commands and 22 functions using a single data type.  And I could ping 100's or 1000's of docs and other clinicians about an idea.

It would appear that today's environment is a flipflop of this.  We are facing 100's or 1000's of standards, committees, interfaces, and legal agreements focused intensely on megacentralization of the "enterprise" view of health.  If I squint really hard, I can find an occasional reference to "patient," but this is quite rare, and, I suspect, on the verge of being deprecated and replaced by "consumer."

The real issue is whether the future architecture is to be patient-centric or enterprise-centric.  

We have patient-centric one that is saving lives today.  At the very least, any future architecture should do the same.

It's like a committee designing a fast, long-range, short take off aircraft.  Someone proposes a 777 body for speed, and another proposes adding helicopter rotors to do short take offs.  Another, noticing the added weight, adds external fuel tanks to maintain the range.  Sooner (preferably) or later, the engineers would say, "this thing has to fly."  This isn't going to work.  They have a Prime Directive - the plane has to fly.

I fear that Health IT committees don't have the same contraints - their response to the above configuration would be to set up a standards committee to define the bolts for the external fuel tanks, and then a harmonization committee to insure the interoperability of the fuel from the external tanks to the internal ones.  There is no analogous Prime Directive in Health IT ... no one is saying, "this system has to work" but rather saying, "everyone has to follow standards" and then taking a leap of faith that the standards will lead to a working system.

I would vote for retaining a patient-centric architecture, and adopting a Prime Directive that the new system enjoys the same clinical support and saves as many or more lives as the current system.

 

like0

Quick Uninformed Response

Van Curtis's picture

 

 My apologies -- I keep meaning to study up and think this out, but I need to stick my foot in the foor. At the very least so somebody can assure me that it's already covered:  The very first step to refactoring VistA is to stake out the current functionality with automated regression testing down to the unit level as much as possible. The most robust open source projects do this. If we want to keep VistA clinical grade we need to do it, too. Period. Otherwise we are just rewriting. The way that you shrink VistA into a more managable code base is by assuring that modifying existing code doesn't break it. Currently in the VA, you can either go through an arduous process of IV&V, ORT, C&A, ATO, etc. -- don't worry about the acronyms, it amounts to trying to kill a fly with a jackhammer -- for what should be little mods and you still won't know definitively that you haven't broken something, or you can write your own custom code and go through the arduous process of IV&V, ORT, C&A, ATO, etc. and at least know you haven't accidentally hosed somebody else. When you need to upgrade your own code, you can at least maybe remember what your stuff was supposed to do and maybe not break it if you're good enough. And when you retire, it will live on forever... This problem is not a MUMPS/VistA problem per se, it's what happens when stuff builds up. I was told MUnit was going Class 1 two years ago, but apparently it isn't yet. I don't know why. I hope that people who know more MUMPS/VistA than I will grab this bull by the horns and then tell the OSEHRA community, "refactor all you want -- just don't screw up the existing functionality. And prove that you haven't." I know that's everyone's goal, but that's what we have to start with, not end with. Again apologies for the abrupt response -- I could be totally wrong about everything. And I certainly don't intend to point fingers or blame anybody in OSEHRA or VA (past or present) -- just presenting the perspective of a blunt software engineer. Thanks - van.
like0

Testing

Afsin Ustundag's picture

Testing is an integral part of this project.  At this point we are working on our testing strategy and trying to get as much from VA as possible in terms of test plans, processes, etc.  It is being done in the context of Problem List package.  One reason we chose this package is it looked to be small enough so that a testing suite is achieavable with relatively small size of our team. 

We are looking for info on MUnit.  I think it is on Certification white paper as well as one of the tools to be investigated.  If you can let us know a contact on how to get/use MUnit we can certainly make it part of our testing strategy.  

like0

What about XINDEX?

Van Curtis's picture

Thought I saw a post here somewhere about XINDEX being rewritten -- was that subject to automated regression testing? I'd think that would be an even better place to start than Problem List.

The head of the VA delegation should be able to direct you to the appropriate VA person.

like0

New XINDEX

Wes Turner's picture

To the best of my knowledge, we have not had a new submission on XINDEX to either the OSEHRA Technical Journal, or to a GERRIT Review, so no modifications are currently under consideration for software quality certification or for formal acceptance into the OSEHRA code base. It may exist in the wild or in the refactoring groups personal sandbox.

If a modified XINDEX is submitted, it will require automated testing.  To the extent that the old XINDEX and the modified XINDEX differ, the changes would have to be explained by the submission and accepted by the reviewers as appropriate.

- Wes

like0

XINDEX

Afsin Ustundag's picture

We are working on a XINDEX based tool that will give us dependencies but at this point that tool will have its own code base.   At this point we are not planning to change/put tests for XINDEX code itself since that will not provide any value for functional testing of a Vista package.

Once we contribute it can be decided by the community if it is something that should replace XINDEX.

like0

100% Agreement on the Testing Front

Wes Turner's picture

Van makes an excellent point and one that needs a reply.  OSEHRA has a powerful infrastructure that automates module (unit) and regression testing.  The tests are run Nightly and are reported to a Dashboard that maintains a running history of test failures and successes.  Additional hooks are available that allow developers to submit "Experimental" submissions that encapsulate the performance of the tests on a developers personal version of the code.  This allows developers to test the code as they make modifications and to flag and fix errors early in the development cycle.  The system is the same as that used in the development of a number of open source toolkits such as ITK, VTK, and others.  A list of public dashboards can be found at http://my.cdash.org/.

The issue with the OSEHRA codebase is that the FOIA contains over 25,000 individual routines but no module or unit tests. We are working to obtain whatever we can from the VA and are adding some minimal testing ourselves, but regardless, the Software Quality Certification process requires that unit and regression tests be part of any submission to the software quality certification process.  Before the results of the refactoring can be accepted, they will need to be augmented with tests, and the tests will be run against both the current and refactored versions of the code.  

We would recommend that after the refactoring group chooses a topic and begins work, their first step would be to write or obtain a comprehensive set of tests for the topic and submit them to the testing repository.  This will allow themselves and the broader community to see the results of their tests on the current code base and to validate the tests as sufficient and correct. Then as they begin to refactor they can use a series of Experimental submissions to track and verify the correctness of their code so that when they reach the software quality certification stage everything works smoothly.

The OSEHRA certification group would be happy to provide whatever support is necessary to get the ball rolling and to adapt the tools to their specific needs.

- Wes

like0

Support

Afsin Ustundag's picture

We are working on testing plans for Problem List and it will be submitted before any code changes.  If you get anything from VA before we do please post. 

Per support, we already asked OSEHRA on how to get test data into the system something that we are researching on our end as well. If you have an update on that it would be great.  That is probably the biggest obstacle on our end at this point.  It is also not clear at least on my mind how data will be cleared and reloaded between individual tests. 

 

like0

Ahhh...

Van Curtis's picture

 @austendag -- thanks for the clarification. I was referring to this post by Kathleen that I read to fast:

http://www.osehra.org/blog/hardest-part-design%E2%80%A6is-keeping-features-out-donald-norman

It just looked like it was being put back into VistA. So what you're saying is that there's going to be something that is not XINDEX but based on it that could sit side-by-side -- YINDEX? XINDEX++ ;-)

I do believe that it would provide value to have a robustly tested XINDEX because it's kind of like understanding how the equals sign works in code. If you overload the equality sign, you need to explain how it works. Best way to do that is in the tests.

thanks for the explanations and patience folks. - van

like0

XINDEX

Afsin Ustundag's picture

Yes. We went back and forth on either doing the changes we needed for our dependency map on the XINDEX itself or just copy it and work it as a new tool.  In the end I thought generating automated tests for 60 and so SAC error messages was less of a priority for us than say functional testing or understanding Problem List code better at this stage in this project.  Actually it is not only SAC error messages that you need tests for, you need tests for "Faux Routine" functionality, you need tests for the output that OSEHRA is currently using for the visual tool, etc.

We also heard that there were either changes to XINDEX itself or to the code base that OSEHRA has to actually reduce the number of errors that XINDEX currently gives.  Not sure what the final on that is.  Until the current code is fully "XINDEX certified" there is really no point of introducing extra complication by changing the XINDEX code. 

 

like0

XTMUnit -- Your New Bread Slicer

Van Curtis's picture

Joel Ivey posted it yesterday:

https://github.com/OSEHR/M-Tools

See this for instructions:

https://github.com/OSEHR/M-Tools/blob/master/Utilities%20XT_7.3_81%20not%20yet%20released/XT_7.3_81%20M-UNIT%20tests,%20XTMRPRNT,%20M-Unit%20GUI.txt

I come from the Test Driven Development world, and this lets me do my thing in MUMPS/VIstA. I'm trusting that Joel knows what he's doing on the M side of things...  ;-)

So apologies to all if you've already seen this and OSEHRA already has this functionality elsewhere -- this is what I've been waiting for. To borrow from the phrase "better than sliced bread" here's your new bread slicer. Enjoy!

like0

Working for today's Veterans

Wes Turner's picture

Van,

We (well mainly Luis Ibanez) have been actively encouraging Joel to submit
this code for exactly the same reason! Now that it is there, we will be
exploring how to incorporate this testing into our automated test
framework, with the goal of getting a test fixture template that uses MUnit
added to the infrastructure as quickly as possible. This should ease the
addition of tests to the system. If you have/are developing MUnit tests
that you would like to submit, let us know. We will be happy to work with
you or help you to incorporate your tests into the dashboard.

- Wes

On Tue, Jan 17, 2012 at 8:21 PM, vancurtis <van.curtis@va.gov> wrote:

> Joel Ivey posted it yesterday:
>
> https://github.com/OSEHR/M-Tools
>
> See this for instructions:
>
> https://github.com/OSEHR/M-Tools/blob/master/Utilities%20XT_7.3_81%20not...
>
> I come from the Test Driven Development world, and this lets me do my
> thing in MUMPS/VIstA. I'm trusting that Joel knows what he's doing on the M
> side of things... ;-)
>
> So apologies to all if you've already seen this and OSEHRA already has
> this functionality elsewhere -- this is what I've been waiting for. To
> borrow from the phrase "better than sliced bread" here's your new bread
> slicer. Enjoy!
> --
> Full post: http://www.osehra.org/blog/working-todays-veterans
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/433
>

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

like0

Some are already available

Christopher Edwards's picture

Wes:

There are unit tests for the code Joel has to get started.  I remember seeing some other unit tests that depend on MUnit elsewhere, I will see if I can find them.

See the ZZUT* routines in:  https://github.com/OSEHR/M-Tools/tree/master/M-Debugger%20for%20Eclipse%20XT_7.3_107%20not%20yet%20released  There are others in the rest of the M* tools

Christopher

like0

Working for today's Veterans

Wes Turner's picture

Thanks Christopher.

- Wes

On Wed, Jan 18, 2012 at 9:37 AM, Christopher.Edwards <
Christopher.Edwards@krminc.com> wrote:

> Wes:
>
> There are unit tests for the code Joel has to get started. I remember
> seeing some other unit tests that depend on MUnit elsewhere, I will see if
> I can find them.
>
> See the ZZUT* routines in:
> https://github.com/OSEHR/M-Tools/tree/master/M-Debugger%20for%20Eclipse%...
> There are others in the rest of the M* tools
>
> Christopher
> --
> Full post: http://www.osehra.org/blog/working-todays-veterans
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/433
>

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

like0