VistA Novo Project Overview

VistA Novo Project Overview

VistA Novo Project Overview

The VistA Novo project is investigating the feasibility of an open source VistA developer toolkit. The goal of this toolkit is to allow developers working in the open source community to use and contribute to VistA capabilities using mainstream architectural approaches and modern programming languages.

The first phase of this project is near-term activity to implement an open source VistA developer toolkit proof of concept, initially focused on the use of JavaScript to build applications on top of VistA. Two specific components under active development (with references to their respective code repositories) are:

1.     A Test Stub that mocks the prospective behavior of services built on top of VistA that may not exist and can be used by application developers to test their JavaScript applications. (https://github.com/OSEHRA/vista-novo-test-stub)

2.     A FHIR implementation to make available VistA test health data following the FHIR specification. (https://github.com/OSEHRA/vista-novo-fhir)

The anticipated products from the first phase include proof of concept capabilities for an open source VistA developer toolkit with sufficient source code to verify the toolkit approach and viability. This includes services to expose VistA data following the FHIR specification, a backend that can invoke VistA-based services to populate FHIR-based data models, and a testing stub to simulate VistA based services. The first release of these products is expected to occur by the end of December 2013.

For more information, send an email to vistanovo@groups.osehra.org .

 

Background

The Department of Veterans Affairs (VA) Architecture, Strategy, and Design (ASD) organization is sponsoring a pathfinder activity with the targeted outcome of achieving technical contributions to accelerate open source VistA’s ability to successfully serve our nation and share information with entities that do not use VistA.

The open source VistA developer toolkit is intended to support this outcome by making it easier to extend and modify the VistA platform providing an avenue for innovative applications using VistA data and business logic, encouraging greater utilization of VistA’s vast feature set by the community, and easier integration through tooling for Health IT standards. Furthermore, the developer toolkit is aiming to lower the barrier to entry for small and resource constrained organizations to enable greater participation in the VistA community by new developers and leverage community innovation.

like0

Comments

Will this use EWD.js?

Rob Tweed's picture

Is the intention to build on EWD.js and its existing, working integration with VistA?

See http://gradvs1.mgateway.com/download/EWDLite.pdf

(EWD Lite has recently been renamed EWD.js and the documentation will be modified soon to reflect this)

Rob

 

like0

The intention is to work with

Andrew J. (Andy) Gregorowicz's picture

The intention is to work with services that can expose data from VistA. We are primarily focused on building a FHIR based interface to those services. So, if someone creates services that expose data from VistA using EWD.js, then the toolkit should be able to consume them.

There are probably opportunities to move the JavaScript code "closer" to the M backend howerer, executing the proper business logic to properly work with the VistA based data will be key there.

 

like0

Haven't we been doing this already?

Augie Turano's picture

I have been using VB/C# and Silverlight with Cache and web webservices and  other technologies like TCP channels for 10 years or more but it would be nice to consolidate and standardize some api's.

like0

By standardized APIs, do you

Salim Semy's picture

By standardized APIs, do you mean standard interfaces to VistA services? Would love your thoughts on what should be included in such a standard. Also, would you be able to further describe the type of VB/C# applications that you're developing on top of VistA to help inform requirements for a VistA developer toolkit?

like0

A couple of requirements

Christopher Edwards's picture
From my POV i'd like to see any developed APIs follow the following: 
  1. Silent APIs (some VistA APIs aren't silent :) )
  2. Return as an extrinsic function (Return a value of some sort - even just an error status)
  3. Documentation of APIs
  4. Simplicity (don't try to do everything in one API, and don't have 100 arguments)
like0

Take a look at what Oroville Hospital are doing

Rob Tweed's picture

Zach Gonzales is the person to consult.  He's creating JavaScript functions that invoke existing Fileman APIs etc.  

The inputs and outputs are JSON objects.

These functions can be used for both browser applications and web services.

His work provides a good basis on which the community can build.

 

like0

Call for joint efforts with http://vista.caregraf.info

Ivan Metzlar's picture

I would like to call for joint efforts with http://vista.caregraf.info/ to complete the FMQL INSERT/UPDATE feature. I'm willing to help implement this if Caregraf is on board. I've been using FMQL as FILEMAN database API after testing RPC+TCP, EWD and others but the FMQL interface is just too simple and easy to NOT use. If FMQL would get write features (or RPC interfaces) it would empower VistA with redis/couchdb/mongodb features and a less steep learning curve for VistA newbies.

like0

web of data

Christopher Edwards's picture

Ivan:

If you didn't see the web-of-data group has been reinvigorated and the caregraf people are part of that group too.

http://www.osehra.org/blog/reinvigoration-semantic-interconnectedness

like0

VistA Novo Project Overview

Dave Hill's picture

I think it would be great to capture all of these ideas and enter them into JIRA so that we have a centralized list that the community can discuss and determine the best resolution, perhaps by teaming together through raised awareness. Please file your ideas into JIRA as a feature request.

Thanks!
Dave

On Oct 29, 2013, at 2:32 PM, ivanmetzlar wrote:

I would like to call for joint efforts with http://vista.caregraf.info/ to complete the FMQL INSERT/UPDATE feature. I'm willing to help implement this if Caregraf is on board. I've been using FMQL as FILEMAN database API after testing RPC+TCP, EWD and others but the FMQL interface is just too simple and easy to NOT use. If FMQL would get write features (or RPC interfaces) it would empower VistA with redis/couchdb/mongodb features and a less steep learning curve for VistA newbies.

--
Full post: http://www.osehra.org/content/vista-novo-project-overview
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3298

like0

Just to let you know I am

Chris Casey's picture

Just to let you know I am already working with Conor to enable the FMQL features via EWD.js.

This will enable all of the features in FMQL to be accessible through secure, federated, web-services as provided automatically by EWD.js. I am also working on some example front ends using bootstrap so that this information will be accessible on any platform.

This work is leading towards the linked data initiative as discussed at the Vista Expo last week.

Therefore if the back-end code is extended to provide update capabilities this should also be available.

Chris Casey

like0

The EWD.js train has left the station

Rob Tweed's picture

Thanks Chris!  Further evidence, then, that the EWD.js train has already left the station

Plenty of room onboard for anyone else who doesn't want to be left behind. Tickets are free.

 

 

like0

EWD.js JSON-LD mapping

Rob Tweed's picture

Hopefully Conor's recent work with FMQL and JSON-LD, in combination with the simple mapping provided by EWD.js between Globals and JavaScript objects will make this all a lot simpler.  See:

http://robtweed.wordpress.com/2013/11/20/creating-json-ld-documents-from-within-mumps/

Rob

like0

The EWD.js Architecture, with respect to the VA

Rob Tweed's picture

I've just posted the following article

http://robtweed.wordpress.com/2013/10/29/a-21st-century-architecture-for-the-va-just-do-it/

Hopefully this sets the context for EWD.js with respect to VistA Novo

Rob

like0

VistA Novo Project Overview

Dave Hill's picture

Hi Rob,

The VistA Novo team likes the work that you are doing with EWD.js and we originally looked at incorporating EWD into VistA Novo at the beginning of the project. The focus for the initial version of VistA Novo is to work in conjunction with the VistA Service Assembler (VSA) as part of a unified architecture that pulls together a number of different efforts at the VA. The VistA Novo team is using that collaboration to implement a use case with FHIR as a risk reduction exercise on that emerging HL7 standard. However, it was not necessary to build on EWD for that initial effort. There will likely be opportunities, though, to collaborate in the future.

There has been some concern expressed by the VA VistA experts about calling M routines directly from JavaScript. If the correct routines are not executed or not fully understood, things can get messed up.

FYI, the VA presented their VSA effort at the OSEHRA Working Group on September 17th.

Please let me know if you have any further questions.

Thanks for your interest!
Dave

On Oct 29, 2013, at 11:28 AM, robtweed wrote:

I've just posted the following article

http://robtweed.wordpress.com/2013/10/29/a-21st-century-architecture-for...

Hopefully this sets the context for EWD.js with respect to VistA Novo

Rob

--
Full post: http://www.osehra.org/content/vista-novo-project-overview
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3298

like0

VistA Novo Project Overview

Ivan Metzlar's picture

"There has been some concern expressed by the VA VistA experts about
calling M routines directly from JavaScript. If the correct routines
are not executed or not fully understood, things can get messed up."

How can this be more concerning when called directly from Javascript
instead of an RPC call or mumps prompt?

On Wed, Oct 30, 2013 at 3:34 PM, "Hill, Dave" <dwhill@mitre.org> wrote:
> Hi Rob,
>
> The VistA Novo team likes the work that you are doing with EWD.js and we
> originally looked at incorporating EWD into VistA Novo at the beginning of
> the project. The focus for the initial version of VistA Novo is to work in
> conjunction with the VistA Service Assembler (VSA) as part of a unified
> architecture that pulls together a number of different efforts at the VA.
> The VistA Novo team is using that collaboration to implement a use case with
> FHIR as a risk reduction exercise on that emerging HL7 standard. However,
> it was not necessary to build on EWD for that initial effort. There will
> likely be opportunities, though, to collaborate in the future.
>
> There has been some concern expressed by the VA VistA experts about calling
> M routines directly from JavaScript. If the correct routines are not
> executed or not fully understood, things can get messed up.
>
> FYI, the VA presented their VSA effort at the OSEHRA Working Group on
> September 17th.
>
> Please let me know if you have any further questions.
>
> Thanks for your interest!
> Dave
>
> On Oct 29, 2013, at 11:28 AM, robtweed wrote:
>
> I've just posted the following article
>
> http://robtweed.wordpress.com/2013/10/29/a-21st-century-architecture-for...
>
> Hopefully this sets the context for EWD.js with respect to VistA Novo
>
> Rob
>
> --
> Full post: http://www.osehra.org/content/vista-novo-project-overview
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3298
>
>
>
> --
> Full post: http://www.osehra.org/content/vista-novo-project-overview
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3298
>

like0

Transparent, VistA Expert peer review via NPM

Rob Tweed's picture

Regarding: "There has been some concern expressed by the VA VistA experts about calling M routines directly from JavaScript. If the correct routines are not executed or not fully understood, things can get messed up."

At some point, every interface to or abstraction of VistA functionality, irrespective of the technology or architecture it relates to, requires access to the physical Mumps routines that provide that functionality.  For example, someone using VSA's wizard to create a service would need to be a VistA expert and know which Mumps routines are the correct and appropriate ones to use.  I fail to see what makes EWD.js's direct access to those Mumps routines any more problematic that any other approach being proposed by the various VA initiatives.  Put any tool in the hands of a fool and of course it will create rubbish.  Put it in the hands of an expert and you'll get something that is fit for purpose.

It goes without saying that anyone creating a JSON interface to VistA needs to know what they're doing: they need to be a VistA expert and understand the nuances of the Mumps routines that they use to assemble their interface.  That's why, at Oroville Hospital, it's Zach Gonzales and not anyone else (such as me!) who is building their interfaces for EWD.js.

Critically, it will all come down to a combination of the survival of the fittest interfaces and VistA expert peer review.  The key to the latter is a transparent and readily-available mechanism to allow it to take place easily and simply.  I've not seen such a process described for VSA, but here's how it will work for EWD.js:

The starting point will probably be Zach Gonzales' VistA.js module.  This can be made available to everyone via the Node Package Manager (NPM) which is built into Node.js.  Once there, anyone can install it and use it immediately against their EWD.js-enabled VistA system(s).  They'll have the full source code for every interface in the module, and will be able to see how it uses the underlying VistA Mumps routines and functions to read from/write to VistA.  By further making the VistA.js module available on Github, VistA experts can suggest modifications, enhancements and add alternative interfaces.  This makes it a fully transparent, peer-reviewed process, fully in Open Source, which, I believe, is the OSEHRA goal.

Furthermore, the community isn't restricted to just Zach's VistA.js module.  *Anyone* will be able to create their own alternative interface module and make it available via NPM.  People will be able to search in NPM for VistA interface modules for EWD.js. 

"Survival of the fittest" will ensure that if some fool puts out an interface that uses the wrong VistA routines, it will pretty quickly get either ignored or corrected.

Once again, I'd emphasise that this isn't something theoretical that will be piloted at some point in the future and eventually see the light of day in a year or so: all this can be done *now*, by anyone.

So, I'd encourage all the VistA experts out there to pre-empt the risk of half-wits creating EWD.js JavaScript interfaces that access incorrect Mumps routines, and start creating definitive ones that use the correct ones in the correct ways, and start uploading your modules to NPM to allow everyone to benefit.  It's a very easy process - a few lines of JavaScript and perhaps a small amount of Mumps code to create a wrapper around the appropriate VistA Mumps routines.  As such, most of the expert work can be done by the Mumps experts who understand the VistA routines, their functionality and underlying nuances, in their terms: ie using Mumps code and not a ton of extra unfamiliar languages and technologies.  The JavaScript interface can then be quickly added by...well,  any old fool :-)

If anyone from the VistA expert community is interested in finding out more about how to collaborate in this way and start benefiting the wider user community, I'd suggest the following:

- ask any questions you might have in the EWD Google Group: 

  https://groups.google.com/forum/#!forum/enterprise-web-developer-community

- book yourself onto the next EWD.js training session: this will most likely be at the next WorldVistA Community Meeting in Sacramento about two-thirds through January next year: I'm sure that Nancy Anthracite will be putting out detalls soon.

- download and install EWD.js on your VistA machine and just do it!

 

like0

Pants on FHIR

Rob Tweed's picture

Regarding: "The VistA Novo team is using that collaboration to implement a use case with FHIR as a risk reduction exercise on that emerging HL7 standard. However, it was not necessary to build on EWD for that initial effort. There will likely be opportunities, though, to collaborate in the future."

As it happens, one of the initiatives that I made frequent mention of in my presentations at last week's VistA Expo was HL7 FHIR which is, of course, focused on JSON-LD, and therefore lends itself perfectly to the 100% JSON world of EWD.js.  

Rather interestingly, there was only one initiative and architecture described and discussed at the VistA Expo that went beyond the Powerpoint stage and actually demonstrated real, running code, showing, for example, a VistA system in Surrey, England, being accessed via a Bootstrap-based browser application that was built from scratch in front of the audience and run in Seattle in a matter of a few minutes.

As such, I'd respectfully suggest that if the VA is wanting to conduct a "risk reduction exercise", that EWD.js might actually provide the path of least risk for building a use case with FHIR.  After all, FHIR is just a messaging standard, expressed in JSON terms, and EWD.js can provide a middle-tier to expose those messages for both application developers and SOA clients.

Rather than waiting for the off-chance of an opportunity to collaborate with you in the future, I'd encourage any developers out there to check out HL7 FHIR, roll your sleeves up and start implementing it on top of EWD.js.  I'm happy to provide advice and help to any such interested people: as per by previous comment, contact me (and the rest of the EWD.js development community) via the EWD Google Group:

https://groups.google.com/forum/#!forum/enterprise-web-developer-community

I see no reason why the community couldn't create their own use case for FHIR pretty quickly.  Any volunteers?

 

like0

VistA Novo Project Overview

Dave Hill's picture

Hi Rob,

I didn't mean to suggest that collaboration needs to be done in any formal way - this is open source after all - I think this would be a great way to collaborate! One of the primary components of VistA Novo is implementing a JavaScript module for the HL7 FHIR code generator so that the latest changes to the FHIR standard can be easily captured by just rerunning the generator.

We already have working code at <https://github.com/OSEHRA/vista-novo-fhir> and I think you can reuse a great majority of this code. We would be thrilled to see that.

Thanks!
Dave

On Oct 31, 2013, at 5:16 AM, robtweed wrote:

Regarding: "The VistA Novo team is using that collaboration to implement a use case with FHIR as a risk reduction exercise on that emerging HL7 standard. However, it was not necessary to build on EWD for that initial effort. There will likely be opportunities, though, to collaborate in the future."

As it happens, one of the initiatives that I made frequent mention of in my presentations at last week's VistA Expo was HL7 FHIR which is, of course, focused on JSON-LD, and therefore lends itself perfectly to the 100% JSON world of EWD.js.

Rather interestingly, there was only one initiative and architecture described and discussed at the VistA Expo that went beyond the Powerpoint stage and actually demonstrated real, running code, showing, for example, a VistA system in Surrey, England, being accessed via a Bootstrap-based browser application that was built from scratch in front of the audience and run in Seattle in a matter of a few minutes.

As such, I'd respectfully suggest that if the VA is wanting to conduct a "risk reduction exercise", that EWD.js might actually provide the path of least risk for building a use case with FHIR. After all, FHIR is just a messaging standard, expressed in JSON terms, and EWD.js can provide a middle-tier to expose those messages for both application developers and SOA clients.

Rather than waiting for the off-chance of an opportunity to collaborate with you in the future, I'd encourage any developers out there to check out HL7 FHIR, roll your sleeves up and start implementing it on top of EWD.js. I'm happy to provide advice and help to any such interested people: as per by previous comment, contact me (and the rest of the EWD.js development community) via the EWD Google Group:

https://groups.google.com/forum/#!forum/enterprise-web-developer-community

I see no reason why the community couldn't create their own use case for FHIR pretty quickly. Any volunteers?

--
Full post: http://www.osehra.org/content/vista-novo-project-overview
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3298

like0

Don't understand the code

Rob Tweed's picture

I took a look at:

https://github.com/OSEHRA/vista-novo-fhir

but couldn't tell where or how to begin to decipher how to use it.  Could you point me at any JavaScript in there that could be deployed and would work within Node.js?

 

like0

Build Process

Andrew J. (Andy) Gregorowicz's picture

As mentioned in the README, this project uses the FHIR Build Process described here:

http://wiki.hl7.org/index.php?title=FHIR_Build_Process

You should be able to clone the git repository and then follow the FHIR build process.

The software here generates the JavaScript code to implement FHIR. It does this using the same toolchain that the HL7 FHIR team is using to generate Java, Delphi and C# reference implementations of FHIR.

The code that we currently have generates JavaScript models of FHIR resources using Mongoose. It is also generating controllers using the express.js framework that runs on top of node.js. I will warn you that it is a work in progress and we don't have a complete application working yet.

From your perspective, I could imagine that you could reuse these models and controllers in EWD.js.

Additionally, I tend to load these projects up in Eclipse and run the build from there. You can load the project in build/tools/java/org.hl7.fhir.tools.core and run the org.hl7.fhir.tools.publisher.Publisher class. This will output the JavaScript in the build/implementations/javascript directory.

like0

Rather than me having to go

Rob Tweed's picture

Rather than me having to go through all those hoops with technologies I don't need or care to use (or have the time to learn and deal with), could someone just generate the JavaScript and put it, pre-built, into the repo on Github?

 

like0

+1  would be nice to be able

Mark Silverberg's picture

+1 

would be nice to be able to peruse the JS without having to build yourself  

like0

Of course. We are just

Andrew J. (Andy) Gregorowicz's picture

Of course. We are just getting started. We wanted to get our code out there as quickly as possible. Java isn't my weapon of choice either, however this seemed like the quickest way to implement FHIR in JavaScript.

Right now, our model generation is fairly stable, but there is a lot of work to be done in the controller layer. I'd feel a little bad just putting out the JavaScript without people digging in and seeing "how the saussage is made" at this point since I see it as very subject to change. But this seems like something we should try to set up soon.

like0

EWD.js approved by the VA

Rob Tweed's picture

I have to thank Steve Owen for pointing out this, which seems to have happened quietly in the last few weeks:

http://www.va.gov/TRM/ToolPage.asp?tid=7046%5e

Rob

 

like0

From scratch?

Mark Silverberg's picture

I have a feeling this initiative is going to garner a lot of interest from those not familiar with VistA. Is there a plan to have instructions that work off of a demo/sample VM so people can use their existing development skills that are compatible with the Novo project even if they couldnt have otherwise developers on/for VistA?

 

like0

Test Stub

Andrew J. (Andy) Gregorowicz's picture

This is why we are building a test stub. The goal here is to build a simple, web based tool that will mimic the data that can be found in VistA. We hope that this will aid the the testing and initial ramp up of services. As someone gets their software closer to a production state, then they can start to pull in a "real" VistA instance (virtual or otherwise).

Does this sound like a reasonable approach?

like0

@gregorowicz - that sounds

Mark Silverberg's picture

@gregorowicz - that sounds great. My bad for not fully looking into what the test stub was.

like0

Automated VistA test instance

Christopher Edwards's picture

Figured I'd inform this group that an automated way to setup a test/development VistA instance using vagrant, virtualbox and git. This may not be useful right now but actually hooking it up to VistA I would think it would be incredibly useful.

I'd also +1 Rob Tweed's suggestion of using EWD.js as the VistA integration would be useful and beneficial.

like0

Forgot the link to the blog post

Christopher Edwards's picture

Clarify please.. node.js & VistA.. where does this fit in?

Tony Shannon's picture
Guys,Could you clarify whats going on here please.. I've recently posted a comment elsewhere on a related subject but need to reiterate here.. 1) Most of us are involved in this space as we have an interest in Mumps the database/the Universal NoSQL Database/ideal for healthcare.. 2) Many of us have an interest in bridging that gap between M the DB and the Web..so a conclusion that javascript, json and node.js as key tools to create that join shouldnt be any surprise to anyone who keeps up with the way the web is developing.. 3) In blending the power of M with the world of the web, we already have EWDLite (now renamed EWD.js) as the node library that brings these M and Web worlds together.. for both service orientation of architecture and front end UI web development....which I'm sure you are already aware of..http://robtweed.wordpress.com/2013/06/16/announcing-ewd-lite/http://robtweed.wordpress.com/2013/10/29/a-21st-century-architecture-for-the-va-just-do-it/ So given your understanding of EWD.js, can you please help me understand the scope/role/function of this Novo effort? thanks Tony Shannonhttp://frectal.com/2013/09/18/transatlantic_thoughts_onvista_nhs/ 
like0