Relationship between VistA Novo and EWD

Relationship between VistA Novo and EWD

Relationship between VistA Novo and EWD

VistA Novo Components

VistA Novo is an open source toolkit developers can use to build VistA-based applications using mainstream development tools. It consists of three primary components:

  1. Service Invocation component to access VistA functions and data.
  2. Data Storage component to make available test data for development purposes during build-time and to cache data locally for performance optimization during run-time.
  3. FHIR Service component to expose VistA data following the FHIR specification.

VistA Novo interaction with VistA-based services within a VA environment

The first picture illustrates the current focus of VistA Novo within a VA environment, where the VistA Novo FHIR Implementation invokes VistA-based Services that sit on top of the Cache Suite to make available VistA data following the FHIR specification. These VistA-based services may be generated using the VistA Service Assembler or via other means. The Testing Stub (also being developed under the VistA Novo project) provides an initial service interface that mocks the behavior of future/under development VistA-based services for testing purposes.

VistA Novo interaction with VistA-based services within an open source environment

The second picture illustrates how the FHIR Implementation can be used on top of an open source stack, including GT.M and EWD. The notion is that VistA-based services would be developed using EWD. Whether the VistA-based service back-end is based on Cache or GT.M and EWD is transparent to the FHIR Implementation.

VistA Novo interaction with EWD

The third picture illustrates an approach where the FHIR Implementation, specifically the FHIR-generated JavaScript objects would interact directly with EWD, rather than via an intermediate VistA-based services layer. I believe this was the approach that Rob Tweed was recommending.

 

Comparison of a VistA-based Services vs. Enterprise Web Development Approach

VistA-based Services Layer:

Pros:

  • Supports data federation across VA sites,
  • Abstracts complexities of VistA MUMPS routines
  • Exposes authoritative, business services meaningful to consumers

Cons:

  • Potential challenges with maintainability (duplicative services, etc.)
  • Potential performance issues

EWD Layer:

Pros:

  • Performance benefit, removes one extra service invocation
  • Lean architecture, fewer moving parts
  • Greater flexibility in interacting with VistA MUMPS routines and data, easier to expose functionality using JavaScript approach

Cons:

  • Requires expertise in VistA and to understand nuances in MUMPS routines, working in same execution space with access to MUMPS routines

 

Transition from VistA-based Services to an EWD-based Approach

There are a number of components that need to be updated in VistA Novo to go from a VistA-based Services approach to an EWD-based approach. The figure below illustrates the changes.

The FHIR Services component remains unchanged.

The Data Storage component in the current VistA-based services approach consists of mongoose objects that are auto-generated and follow the FHIR specification. Mongoose is a MongoDB object modeling utility with built-in type casting, validation, query building, and business logic hooks. To move to an EWD-based approach, the code that auto-generates the mongoose objects needs to be modified to generate plain JavaScript objects so that it can work within the EWD framework. This is expected to be about 1 week of effort to update the auto-generation code.

The Service Invocation component will require the greatest changes to move from a VistA-based Services approach to an EWD-based approach. JavaScript APIs need to be implemented to call underlying M routines. These APIs will vary depending on the function of the application being developed in JavaScript. Since there exists an effort to auto-create VistA-based Services that access M routines, the idea is to leverage the service descriptors of these VistA-based Services to auto-generate (at least an initial skeleton) JavaScript API that corresponds to each service. The level of effort to generate JavaScript APIs corresponding to a particular VistA-based Service requires further investigation.

 

Transition to an EWD-Based Approach Summary

Presently, VistA Novo is targeted to provide a VistA Developer Toolkit that allows both VA and open source developers to:

  • Test their JavaScript applications against a test stub that mocks the prospective behaviour of VistA-based services
  • Consume VistA data in a format that follows the FHIR specification

This aligns well with the VA’s current path to implement the VistA Service Assembler that will generate the VistA-based services. However, the open source VistA community is moving in a direction where extensions to VistA are through JavaScript code that interacts directly with M routines (rather than via intermediate VistA-based services).

Transitioning VistA Novo to an EWD-based approach ensures closer alignment with the direction of the broader open source VistA community while providing an ability to extend VistA using JavaScript, and eventually additional mainstream technologies.

Level of Effort:

  • FHIR Services component: None
  • Data Storage component: 1 week of development to auto-generate plain JavaScript objects
  • Service Invocation component: 1 month of development time to convert a VSA service descriptor to an EWD.js based JavaScript API. This will create a tool that can repurpose the service descriptors for any service that is created with VSA tooling.

Need to revisit VA-specific considerations, including federation across multiple VA medical centers and the desire for authoritative business services.

Any comments/edits to the depictions above are welcome.

like0

Comments

This looks to be a much

Chris Casey's picture

This looks to be a much simpler model with fewer moving parts and therefore more maintainable.

I do wonder why picture 3 specifies Vista on GT.M. Surely this model applies equally to Vista on Cache?

One simple model for both environments has to be the way to go forward.

Also this model should not be though of as specific to FHIR it applies equally to other interactions.

like0

Relationship between VistA Novo and EWD

Salim Semy's picture

Chris,

Yes, technically it can be GT.M or Cache on the back-end. The question is whether it's a likely scenario in the open source community?

I agree, one simple model would be ideal. I guess the question is whether it's approach 1/2 or 3 or something else? Maybe we should list the pros and cons for each approach. I'll put a starting point on the wiki, please contribute.

Salim

From: ChrisUK <borochris9@gmail.com<mailto:borochris9@gmail.com>>
Date: Friday, November 8, 2013 5:13 AM
To: "VistA Novo: Open Source VistA Developer Toolkit" <vistanovo@groups.osehra.org<mailto:vistanovo@groups.osehra.org>>
Subject: Re: [vistanovo] Relationship between VistA Novo and EWD

This looks to be a much simpler model with fewer moving parts and therefore more maintainable.

I do wonder why picture 3 specifies Vista on GT.M. Surely this model applies equally to Vista on Cache?

One simple model for both environments has to be the way to go forward.

Also this model should not be though of as specific to FHIR it applies equally to other interactions.

--
Full post: http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3343

like0

Fair summary

Rob Tweed's picture

This seems like a reasonable summary to me of the approaches available.  I'd just clarify that in Figures 2 and 3, it should show the database layer as being GT.M *or* Cache, not just GT.M

That highlights the clear difference between the approaches shown in 1 and 3.  The current focus of VistA Novo is completely Cache-dependent and reliant on Cache-specific functionality and interfaces, and only serves the specific requirements of VistA Novo in delivering FHIR services.

Approach 3 is completely generic - it can work at both the VA and in the Open-Source non-VA community, and it makes use of a generic architecture (courtesy of EWD.js) that can support all other VistA-related activity.

My inevitable question would be, other than the fact that approach 1 is probably already under development for the purposes of a VistA Novo/FHIR demonstrator, does it have any long-term justification or viability?  Ditto for approach 2, since this is unnecessarily adding an extra set of moving parts and layers that detract from the maintainability and potential performance.

 

Rob

 

 

like0

Relationship between VistA Novo and EWD

Sam Habiel's picture

Ditto with Rob.

I am actually pretty concerned that the first and second diagrams have
another storage layer outside of VISTA.

Sam

On Fri, Nov 8, 2013 at 2:21 AM, robtweed <rtweed@mgateway.com> wrote:
> This seems like a reasonable summary to me of the approaches available. I'd
> just clarify that in Figures 2 and 3, it should show the database layer as
> being GT.M *or* Cache, not just GT.M
>
> That highlights the clear difference between the approaches shown in 1 and
> 3. The current focus of VistA Novo is completely Cache-dependent and
> reliant on Cache-specific functionality and interfaces, and only serves the
> specific requirements of VistA Novo in delivering FHIR services.
>
> Approach 3 is completely generic - it can work at both the VA and in the
> Open-Source non-VA community, and it makes use of a generic architecture
> (courtesy of EWD.js) that can support all other VistA-related activity.
>
> My inevitable question would be, other than the fact that approach 1 is
> probably already under development for the purposes of a VistA Novo/FHIR
> demonstrator, does it have any long-term justification or viability? Ditto
> for approach 2, since this is unnecessarily adding an extra set of moving
> parts and layers that detract from the maintainability and potential
> performance.
>
>
>
> Rob
>
>
>
>
>
> --
> Full post:
> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3343

like0

Storage Layer Outside of VistA

Peter Li's picture

It would great if Salim can lay out the rational for the storage layer.  Is it a use case specific requirement or is there a architectural justification due to performance requirement as in the Virtual Patient Record (VPR) storage used by the Health Management Platform (HMP) group.

like0

Relationship between VistA Novo and EWD

Salim Semy's picture

Hi Peter,

The storage layer is there primarily for performance and ease of implementation.

Salim

From: petercyli <lip@osehra.org<mailto:lip@osehra.org>>
Date: Friday, November 8, 2013 1:18 PM
To: "VistA Novo: Open Source VistA Developer Toolkit" <vistanovo@groups.osehra.org<mailto:vistanovo@groups.osehra.org>>
Subject: Re: [vistanovo] Relationship between VistA Novo and EWD

It would great if Salim can lay out the rational for the storage layer. Is it a use case specific requirement or is there a architectural justification due to performance requirement as in the Virtual Patient Record (VPR) storage used by the Health Management Platform (HMP) group.

--
Full post: http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3343

like0

Relationship between VistA Novo and EWD

Sid T's picture

Salim -

Could you provide some specifics on how the storage layer improves
performance and eases implementation?

Sid Tarason

On Fri, Nov 8, 2013 at 2:03 PM, "Semy, Salim K." <ssemy@mitre.org> wrote:

> Hi Peter,
>
> The storage layer is there primarily for performance and ease of
> implementation.
>
> Salim
>
> From: petercyli <lip@osehra.org>
> Date: Friday, November 8, 2013 1:18 PM
>
> To: "VistA Novo: Open Source VistA Developer Toolkit" <
> vistanovo@groups.osehra.org>
> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>
> It would great if Salim can lay out the rational for the storage layer.
> Is it a use case specific requirement or is there a architectural
> justification due to performance requirement as in the Virtual Patient
> Record (VPR) storage used by the Health Management Platform (HMP) group.
> --
> Full post:
> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>
> --
> Full post:
> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>
>

like0

Relationship between VistA Novo and EWD

Salim Semy's picture

Sure. With respect to performance, the intent is for the storage layer to provide a cache of the data, so the first time a particular piece of data is requested it goes to the VistA based service to get the data. If it is requested again, the data is cached for local retrieval rather than needing to invoke the service again.

On ease of implementation, having a MongoDB on the backend for data storage enables us to use Mongoose to maintain the nested structures inside of each FHIR resource. The other option would be to have plan old JavaScript objects, but then we would need to write the validation code ourselves.

I hope this helps.

Salim

From: Sidney Seo <seosidney@gmail.com<mailto:seosidney@gmail.com>>
Date: Monday, November 11, 2013 3:21 PM
To: "vistanovo@groups.osehra.org<mailto:vistanovo@groups.osehra.org>" <vistanovo@groups.osehra.org<mailto:vistanovo@groups.osehra.org>>
Subject: Re: [vistanovo] Relationship between VistA Novo and EWD

Salim -

Could you provide some specifics on how the storage layer improves performance and eases implementation?

Sid Tarason

On Fri, Nov 8, 2013 at 2:03 PM, "Semy, Salim K." <ssemy@mitre.org<mailto:ssemy@mitre.org>> wrote:
Hi Peter,

The storage layer is there primarily for performance and ease of implementation.

Salim

From: petercyli <lip@osehra.org<mailto:lip@osehra.org>>
Date: Friday, November 8, 2013 1:18 PM

To: "VistA Novo: Open Source VistA Developer Toolkit" <vistanovo@groups.osehra.org<mailto:vistanovo@groups.osehra.org>>
Subject: Re: [vistanovo] Relationship between VistA Novo and EWD

It would great if Salim can lay out the rational for the storage layer. Is it a use case specific requirement or is there a architectural justification due to performance requirement as in the Virtual Patient Record (VPR) storage used by the Health Management Platform (HMP) group.

--
Full post: http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3343

--
Full post: http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3343

like0

Relationship between VistA Novo and EWD

DAVID Whitten's picture

Since the VistA system is the system of record, what is your strategy
for invalidating the cache as a MongoDB data store?

Any EHR will be constantly changing, as it is maintained by multiple
programs (and people) within the care facility.

In my opinion, unless you are only dealing with historic data (older
than a month or so), the cache would be invalidated so often that you
would be best served by allowing the VistA system to be your data
store.

You could use Sam Habiel's web server built on top of Virtual Patient
Record (VPR) storage to get the data in a JSON or XML format, or the
FHIR data records directly. Presumably, there is some form of linear
form of the FHIR data, which should be isomorphically mapped to the
internal VistA structures.

David

On Tue, Nov 12, 2013 at 10:47 AM, "Semy, Salim K." <ssemy@mitre.org> wrote:
> Sure. With respect to performance, the intent is for the storage layer to
> provide a cache of the data, so the first time a particular piece of data is
> requested it goes to the VistA based service to get the data. If it is
> requested again, the data is cached for local retrieval rather than needing
> to invoke the service again.
>
> On ease of implementation, having a MongoDB on the backend for data storage
> enables us to use Mongoose to maintain the nested structures inside of each
> FHIR resource. The other option would be to have plan old JavaScript
> objects, but then we would need to write the validation code ourselves.
>
> I hope this helps.
>
> Salim
>
> From: Sidney Seo <seosidney@gmail.com>
> Date: Monday, November 11, 2013 3:21 PM
> To: "vistanovo@groups.osehra.org" <vistanovo@groups.osehra.org>
>
> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>
> Salim -
>
> Could you provide some specifics on how the storage layer improves
> performance and eases implementation?
>
> Sid Tarason
>
>
> On Fri, Nov 8, 2013 at 2:03 PM, "Semy, Salim K." <ssemy@mitre.org> wrote:
>>
>> Hi Peter,
>>
>> The storage layer is there primarily for performance and ease of
>> implementation.
>>
>> Salim
>>
>> From: petercyli <lip@osehra.org>
>> Date: Friday, November 8, 2013 1:18 PM
>>
>> To: "VistA Novo: Open Source VistA Developer Toolkit"
>> <vistanovo@groups.osehra.org>
>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>
>> It would great if Salim can lay out the rational for the storage layer.
>> Is it a use case specific requirement or is there a architectural
>> justification due to performance requirement as in the Virtual Patient
>> Record (VPR) storage used by the Health Management Platform (HMP) group.
>>
>> --
>> Full post:
>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>
>> --
>> Full post:
>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>
>
>
> --
> Full post:
> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>

like0

Relationship between VistA Novo and EWD

Sam Habiel's picture

It's worth mentioning that HMP uses a similar approach to caching.
Kevin, (copied), can give you more details.

I remember Kevin saying that Mongo DB was pretty slow; he elected to
use VISTA for Caching instead.

Sam

On Tue, Nov 12, 2013 at 8:09 AM, David Whitten <whitten@netcom.com> wrote:
> Since the VistA system is the system of record, what is your strategy
> for invalidating the cache as a MongoDB data store?
>
> Any EHR will be constantly changing, as it is maintained by multiple
> programs (and people) within the care facility.
>
> In my opinion, unless you are only dealing with historic data (older
> than a month or so), the cache would be invalidated so often that you
> would be best served by allowing the VistA system to be your data
> store.
>
> You could use Sam Habiel's web server built on top of Virtual Patient
> Record (VPR) storage to get the data in a JSON or XML format, or the
> FHIR data records directly. Presumably, there is some form of linear
> form of the FHIR data, which should be isomorphically mapped to the
> internal VistA structures.
>
> David
>
> On Tue, Nov 12, 2013 at 10:47 AM, "Semy, Salim K." <ssemy@mitre.org> wrote:
>> Sure. With respect to performance, the intent is for the storage layer to
>> provide a cache of the data, so the first time a particular piece of data is
>> requested it goes to the VistA based service to get the data. If it is
>> requested again, the data is cached for local retrieval rather than needing
>> to invoke the service again.
>>
>> On ease of implementation, having a MongoDB on the backend for data storage
>> enables us to use Mongoose to maintain the nested structures inside of each
>> FHIR resource. The other option would be to have plan old JavaScript
>> objects, but then we would need to write the validation code ourselves.
>>
>> I hope this helps.
>>
>> Salim
>>
>> From: Sidney Seo <seosidney@gmail.com>
>> Date: Monday, November 11, 2013 3:21 PM
>> To: "vistanovo@groups.osehra.org" <vistanovo@groups.osehra.org>
>>
>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>
>> Salim -
>>
>> Could you provide some specifics on how the storage layer improves
>> performance and eases implementation?
>>
>> Sid Tarason
>>
>>
>> On Fri, Nov 8, 2013 at 2:03 PM, "Semy, Salim K." <ssemy@mitre.org> wrote:
>>>
>>> Hi Peter,
>>>
>>> The storage layer is there primarily for performance and ease of
>>> implementation.
>>>
>>> Salim
>>>
>>> From: petercyli <lip@osehra.org>
>>> Date: Friday, November 8, 2013 1:18 PM
>>>
>>> To: "VistA Novo: Open Source VistA Developer Toolkit"
>>> <vistanovo@groups.osehra.org>
>>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>>
>>> It would great if Salim can lay out the rational for the storage layer.
>>> Is it a use case specific requirement or is there a architectural
>>> justification due to performance requirement as in the Virtual Patient
>>> Record (VPR) storage used by the Health Management Platform (HMP) group.
>>>
>>> --
>>> Full post:
>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>> Manage my subscriptions:
>>> http://www.osehra.org/og_mailinglist/subscriptions
>>> Stop emails for this post:
>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>
>>> --
>>> Full post:
>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>> Manage my subscriptions:
>>> http://www.osehra.org/og_mailinglist/subscriptions
>>> Stop emails for this post:
>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>
>>
>>
>> --
>> Full post:
>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>
>
>
>
> --
> Full post: http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3343
>

like0

Relationship between VistA Novo and EWD

Salim Semy's picture

It would be great if Kevin could share additional details on the HMP
approach to caching.

There are definitely trade-offs with using Mongo DB. Given our initial
goal is to develop a proof-of-concept prototype, the benefits of ease of
implementation made Mongo DB a good option.

Salim

On 11/12/13 11:15 AM, "Sam Habiel" <sam.habiel@gmail.com> wrote:

>It's worth mentioning that HMP uses a similar approach to caching.
>Kevin, (copied), can give you more details.
>
>I remember Kevin saying that Mongo DB was pretty slow; he elected to
>use VISTA for Caching instead.
>
>Sam
>
>On Tue, Nov 12, 2013 at 8:09 AM, David Whitten <whitten@netcom.com> wrote:
>> Since the VistA system is the system of record, what is your strategy
>> for invalidating the cache as a MongoDB data store?
>>
>> Any EHR will be constantly changing, as it is maintained by multiple
>> programs (and people) within the care facility.
>>
>> In my opinion, unless you are only dealing with historic data (older
>> than a month or so), the cache would be invalidated so often that you
>> would be best served by allowing the VistA system to be your data
>> store.
>>
>> You could use Sam Habiel's web server built on top of Virtual Patient
>> Record (VPR) storage to get the data in a JSON or XML format, or the
>> FHIR data records directly. Presumably, there is some form of linear
>> form of the FHIR data, which should be isomorphically mapped to the
>> internal VistA structures.
>>
>> David
>>
>> On Tue, Nov 12, 2013 at 10:47 AM, "Semy, Salim K." <ssemy@mitre.org>
>>wrote:
>>> Sure. With respect to performance, the intent is for the storage layer
>>>to
>>> provide a cache of the data, so the first time a particular piece of
>>>data is
>>> requested it goes to the VistA based service to get the data. If it is
>>> requested again, the data is cached for local retrieval rather than
>>>needing
>>> to invoke the service again.
>>>
>>> On ease of implementation, having a MongoDB on the backend for data
>>>storage
>>> enables us to use Mongoose to maintain the nested structures inside of
>>>each
>>> FHIR resource. The other option would be to have plan old JavaScript
>>> objects, but then we would need to write the validation code ourselves.
>>>
>>> I hope this helps.
>>>
>>> Salim
>>>
>>> From: Sidney Seo <seosidney@gmail.com>
>>> Date: Monday, November 11, 2013 3:21 PM
>>> To: "vistanovo@groups.osehra.org" <vistanovo@groups.osehra.org>
>>>
>>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>>
>>> Salim -
>>>
>>> Could you provide some specifics on how the storage layer improves
>>> performance and eases implementation?
>>>
>>> Sid Tarason
>>>
>>>
>>> On Fri, Nov 8, 2013 at 2:03 PM, "Semy, Salim K." <ssemy@mitre.org>
>>>wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> The storage layer is there primarily for performance and ease of
>>>> implementation.
>>>>
>>>> Salim
>>>>
>>>> From: petercyli <lip@osehra.org>
>>>> Date: Friday, November 8, 2013 1:18 PM
>>>>
>>>> To: "VistA Novo: Open Source VistA Developer Toolkit"
>>>> <vistanovo@groups.osehra.org>
>>>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>>>
>>>> It would great if Salim can lay out the rational for the storage
>>>>layer.
>>>> Is it a use case specific requirement or is there a architectural
>>>> justification due to performance requirement as in the Virtual Patient
>>>> Record (VPR) storage used by the Health Management Platform (HMP)
>>>>group.
>>>>
>>>> --
>>>> Full post:
>>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>>> Manage my subscriptions:
>>>> http://www.osehra.org/og_mailinglist/subscriptions
>>>> Stop emails for this post:
>>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>>
>>>> --
>>>> Full post:
>>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>>> Manage my subscriptions:
>>>> http://www.osehra.org/og_mailinglist/subscriptions
>>>> Stop emails for this post:
>>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>>
>>>
>>>
>>> --
>>> Full post:
>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>> Manage my subscriptions:
>>>http://www.osehra.org/og_mailinglist/subscriptions
>>> Stop emails for this post:
>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>
>>
>>
>>
>> --
>> Full post:
>>http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>> Manage my subscriptions:
>>http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>>http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>
>
>

like0

Relationship between VistA Novo and EWD

Salim Semy's picture

I agree, and think it's important to look at the data refresh and access
patterns and accordingly implement a caching strategy. Vital signs, for
example, are measurements for a particular instance in time. While new
vital sign measurements may be taken, the historic data remains valid for
the particular point in time in which it was taken. If an application
wants to look at vital signs measurements over the past 24 hours, and the
24 hour window continuously shifts to the right, caching can help with
performance. I'm sure there are examples where it's more optimal to go
directly to VistA rather than a cache.

Having said that, right now the VistA Novo implementation is a
proof-of-concept prototype. While we are implementing a cache, I agree
that it's important to consider where caching makes sense and where it
does not.

Salim

On 11/12/13 11:09 AM, "David Whitten" <whitten@netcom.com> wrote:

>Since the VistA system is the system of record, what is your strategy
>for invalidating the cache as a MongoDB data store?
>
>Any EHR will be constantly changing, as it is maintained by multiple
>programs (and people) within the care facility.
>
>In my opinion, unless you are only dealing with historic data (older
>than a month or so), the cache would be invalidated so often that you
>would be best served by allowing the VistA system to be your data
>store.
>
>You could use Sam Habiel's web server built on top of Virtual Patient
>Record (VPR) storage to get the data in a JSON or XML format, or the
>FHIR data records directly. Presumably, there is some form of linear
>form of the FHIR data, which should be isomorphically mapped to the
>internal VistA structures.
>
>David
>
>On Tue, Nov 12, 2013 at 10:47 AM, "Semy, Salim K." <ssemy@mitre.org>
>wrote:
>> Sure. With respect to performance, the intent is for the storage layer
>>to
>> provide a cache of the data, so the first time a particular piece of
>>data is
>> requested it goes to the VistA based service to get the data. If it is
>> requested again, the data is cached for local retrieval rather than
>>needing
>> to invoke the service again.
>>
>> On ease of implementation, having a MongoDB on the backend for data
>>storage
>> enables us to use Mongoose to maintain the nested structures inside of
>>each
>> FHIR resource. The other option would be to have plan old JavaScript
>> objects, but then we would need to write the validation code ourselves.
>>
>> I hope this helps.
>>
>> Salim
>>
>> From: Sidney Seo <seosidney@gmail.com>
>> Date: Monday, November 11, 2013 3:21 PM
>> To: "vistanovo@groups.osehra.org" <vistanovo@groups.osehra.org>
>>
>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>
>> Salim -
>>
>> Could you provide some specifics on how the storage layer improves
>> performance and eases implementation?
>>
>> Sid Tarason
>>
>>
>> On Fri, Nov 8, 2013 at 2:03 PM, "Semy, Salim K." <ssemy@mitre.org>
>>wrote:
>>>
>>> Hi Peter,
>>>
>>> The storage layer is there primarily for performance and ease of
>>> implementation.
>>>
>>> Salim
>>>
>>> From: petercyli <lip@osehra.org>
>>> Date: Friday, November 8, 2013 1:18 PM
>>>
>>> To: "VistA Novo: Open Source VistA Developer Toolkit"
>>> <vistanovo@groups.osehra.org>
>>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>>
>>> It would great if Salim can lay out the rational for the storage layer.
>>> Is it a use case specific requirement or is there a architectural
>>> justification due to performance requirement as in the Virtual Patient
>>> Record (VPR) storage used by the Health Management Platform (HMP)
>>>group.
>>>
>>> --
>>> Full post:
>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>> Manage my subscriptions:
>>> http://www.osehra.org/og_mailinglist/subscriptions
>>> Stop emails for this post:
>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>
>>> --
>>> Full post:
>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>> Manage my subscriptions:
>>> http://www.osehra.org/og_mailinglist/subscriptions
>>> Stop emails for this post:
>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>
>>
>>
>> --
>> Full post:
>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>> Manage my subscriptions:
>>http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>

like0

Relationship between VistA Novo and EWD

Ivan Metzlar's picture

Hi Salim,

I've never heard the requirements caching, proof-of-concept, prototype
and performance together. Why bother about performance when you are
making a proof-of-concept prototype at all?

Cheers,

Ivan

On Wed, Nov 13, 2013 at 9:12 AM, "Semy, Salim K." <ssemy@mitre.org> wrote:
> I agree, and think it's important to look at the data refresh and access
> patterns and accordingly implement a caching strategy. Vital signs, for
> example, are measurements for a particular instance in time. While new
> vital sign measurements may be taken, the historic data remains valid for
> the particular point in time in which it was taken. If an application
> wants to look at vital signs measurements over the past 24 hours, and the
> 24 hour window continuously shifts to the right, caching can help with
> performance. I'm sure there are examples where it's more optimal to go
> directly to VistA rather than a cache.
>
> Having said that, right now the VistA Novo implementation is a
> proof-of-concept prototype. While we are implementing a cache, I agree
> that it's important to consider where caching makes sense and where it
> does not.
>
> Salim
>
>
> On 11/12/13 11:09 AM, "David Whitten" <whitten@netcom.com> wrote:
>
>>Since the VistA system is the system of record, what is your strategy
>>for invalidating the cache as a MongoDB data store?
>>
>>Any EHR will be constantly changing, as it is maintained by multiple
>>programs (and people) within the care facility.
>>
>>In my opinion, unless you are only dealing with historic data (older
>>than a month or so), the cache would be invalidated so often that you
>>would be best served by allowing the VistA system to be your data
>>store.
>>
>>You could use Sam Habiel's web server built on top of Virtual Patient
>>Record (VPR) storage to get the data in a JSON or XML format, or the
>>FHIR data records directly. Presumably, there is some form of linear
>>form of the FHIR data, which should be isomorphically mapped to the
>>internal VistA structures.
>>
>>David
>>
>>On Tue, Nov 12, 2013 at 10:47 AM, "Semy, Salim K." <ssemy@mitre.org>
>>wrote:
>>> Sure. With respect to performance, the intent is for the storage layer
>>>to
>>> provide a cache of the data, so the first time a particular piece of
>>>data is
>>> requested it goes to the VistA based service to get the data. If it is
>>> requested again, the data is cached for local retrieval rather than
>>>needing
>>> to invoke the service again.
>>>
>>> On ease of implementation, having a MongoDB on the backend for data
>>>storage
>>> enables us to use Mongoose to maintain the nested structures inside of
>>>each
>>> FHIR resource. The other option would be to have plan old JavaScript
>>> objects, but then we would need to write the validation code ourselves.
>>>
>>> I hope this helps.
>>>
>>> Salim
>>>
>>> From: Sidney Seo <seosidney@gmail.com>
>>> Date: Monday, November 11, 2013 3:21 PM
>>> To: "vistanovo@groups.osehra.org" <vistanovo@groups.osehra.org>
>>>
>>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>>
>>> Salim -
>>>
>>> Could you provide some specifics on how the storage layer improves
>>> performance and eases implementation?
>>>
>>> Sid Tarason
>>>
>>>
>>> On Fri, Nov 8, 2013 at 2:03 PM, "Semy, Salim K." <ssemy@mitre.org>
>>>wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> The storage layer is there primarily for performance and ease of
>>>> implementation.
>>>>
>>>> Salim
>>>>
>>>> From: petercyli <lip@osehra.org>
>>>> Date: Friday, November 8, 2013 1:18 PM
>>>>
>>>> To: "VistA Novo: Open Source VistA Developer Toolkit"
>>>> <vistanovo@groups.osehra.org>
>>>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>>>
>>>> It would great if Salim can lay out the rational for the storage layer.
>>>> Is it a use case specific requirement or is there a architectural
>>>> justification due to performance requirement as in the Virtual Patient
>>>> Record (VPR) storage used by the Health Management Platform (HMP)
>>>>group.
>>>>
>>>> --
>>>> Full post:
>>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>>> Manage my subscriptions:
>>>> http://www.osehra.org/og_mailinglist/subscriptions
>>>> Stop emails for this post:
>>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>>
>>>> --
>>>> Full post:
>>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>>> Manage my subscriptions:
>>>> http://www.osehra.org/og_mailinglist/subscriptions
>>>> Stop emails for this post:
>>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>>
>>>
>>>
>>> --
>>> Full post:
>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>> Manage my subscriptions:
>>>http://www.osehra.org/og_mailinglist/subscriptions
>>> Stop emails for this post:
>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>
>
>
>
>
> --
> Full post: http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3343
>

like0

Relationship between VistA Novo and EWD

Salim Semy's picture

Hi Ivan,

Yes, performance is not a primary focus for our initial prototype. It's
the FHIR interface.

However, a goal of implementing the proof-of-concept prototype is to
identify the challenges and trade-offs to inform the design of the
eventual system. Thus, we chose to put together a basic implementation of
the components that we think will be useful in the overall system, while
focusing on the FHIR interface. The fact that we're having the discussion
about whether a data storage layer is important or not, implementation
options for the cache, when to cache vs. go back to VistA, etc. speaks for
the value of including basic caching in the initial prototype.

Salim

On 11/13/13 12:27 PM, "Ivan Metzlar" <metzlar@gmail.com> wrote:

>Hi Salim,
>
>I've never heard the requirements caching, proof-of-concept, prototype
>and performance together. Why bother about performance when you are
>making a proof-of-concept prototype at all?
>
>Cheers,
>
>Ivan
>
>On Wed, Nov 13, 2013 at 9:12 AM, "Semy, Salim K." <ssemy@mitre.org> wrote:
>> I agree, and think it's important to look at the data refresh and access
>> patterns and accordingly implement a caching strategy. Vital signs, for
>> example, are measurements for a particular instance in time. While new
>> vital sign measurements may be taken, the historic data remains valid
>>for
>> the particular point in time in which it was taken. If an application
>> wants to look at vital signs measurements over the past 24 hours, and
>>the
>> 24 hour window continuously shifts to the right, caching can help with
>> performance. I'm sure there are examples where it's more optimal to go
>> directly to VistA rather than a cache.
>>
>> Having said that, right now the VistA Novo implementation is a
>> proof-of-concept prototype. While we are implementing a cache, I agree
>> that it's important to consider where caching makes sense and where it
>> does not.
>>
>> Salim
>>
>>
>> On 11/12/13 11:09 AM, "David Whitten" <whitten@netcom.com> wrote:
>>
>>>Since the VistA system is the system of record, what is your strategy
>>>for invalidating the cache as a MongoDB data store?
>>>
>>>Any EHR will be constantly changing, as it is maintained by multiple
>>>programs (and people) within the care facility.
>>>
>>>In my opinion, unless you are only dealing with historic data (older
>>>than a month or so), the cache would be invalidated so often that you
>>>would be best served by allowing the VistA system to be your data
>>>store.
>>>
>>>You could use Sam Habiel's web server built on top of Virtual Patient
>>>Record (VPR) storage to get the data in a JSON or XML format, or the
>>>FHIR data records directly. Presumably, there is some form of linear
>>>form of the FHIR data, which should be isomorphically mapped to the
>>>internal VistA structures.
>>>
>>>David
>>>
>>>On Tue, Nov 12, 2013 at 10:47 AM, "Semy, Salim K." <ssemy@mitre.org>
>>>wrote:
>>>> Sure. With respect to performance, the intent is for the storage layer
>>>>to
>>>> provide a cache of the data, so the first time a particular piece of
>>>>data is
>>>> requested it goes to the VistA based service to get the data. If it is
>>>> requested again, the data is cached for local retrieval rather than
>>>>needing
>>>> to invoke the service again.
>>>>
>>>> On ease of implementation, having a MongoDB on the backend for data
>>>>storage
>>>> enables us to use Mongoose to maintain the nested structures inside of
>>>>each
>>>> FHIR resource. The other option would be to have plan old JavaScript
>>>> objects, but then we would need to write the validation code
>>>>ourselves.
>>>>
>>>> I hope this helps.
>>>>
>>>> Salim
>>>>
>>>> From: Sidney Seo <seosidney@gmail.com>
>>>> Date: Monday, November 11, 2013 3:21 PM
>>>> To: "vistanovo@groups.osehra.org" <vistanovo@groups.osehra.org>
>>>>
>>>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>>>
>>>> Salim -
>>>>
>>>> Could you provide some specifics on how the storage layer improves
>>>> performance and eases implementation?
>>>>
>>>> Sid Tarason
>>>>
>>>>
>>>> On Fri, Nov 8, 2013 at 2:03 PM, "Semy, Salim K." <ssemy@mitre.org>
>>>>wrote:
>>>>>
>>>>> Hi Peter,
>>>>>
>>>>> The storage layer is there primarily for performance and ease of
>>>>> implementation.
>>>>>
>>>>> Salim
>>>>>
>>>>> From: petercyli <lip@osehra.org>
>>>>> Date: Friday, November 8, 2013 1:18 PM
>>>>>
>>>>> To: "VistA Novo: Open Source VistA Developer Toolkit"
>>>>> <vistanovo@groups.osehra.org>
>>>>> Subject: Re: [vistanovo] Relationship between VistA Novo and EWD
>>>>>
>>>>> It would great if Salim can lay out the rational for the storage
>>>>>layer.
>>>>> Is it a use case specific requirement or is there a architectural
>>>>> justification due to performance requirement as in the Virtual
>>>>>Patient
>>>>> Record (VPR) storage used by the Health Management Platform (HMP)
>>>>>group.
>>>>>
>>>>> --
>>>>> Full post:
>>>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>>>> Manage my subscriptions:
>>>>> http://www.osehra.org/og_mailinglist/subscriptions
>>>>> Stop emails for this post:
>>>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>>>
>>>>> --
>>>>> Full post:
>>>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>>>> Manage my subscriptions:
>>>>> http://www.osehra.org/og_mailinglist/subscriptions
>>>>> Stop emails for this post:
>>>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>>>
>>>>
>>>>
>>>> --
>>>> Full post:
>>>> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>>>> Manage my subscriptions:
>>>>http://www.osehra.org/og_mailinglist/subscriptions
>>>> Stop emails for this post:
>>>> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>>>
>>
>>
>>
>>
>> --
>> Full post:
>>http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
>> Manage my subscriptions:
>>http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>>http://www.osehra.org/og_mailinglist/unsubscribe/3343
>>

like0

Relationship between VistA Novo and EWD

Salim Semy's picture

Rob,

Thanks for the clarification. While technically EWD can work on top of Cache (and we can certainly update the figures to reflect this) I'm wondering if this is a likely scenario in the open source community?

Also, the code we are building in VistA Novo will not be Cache dependent. Our goal was to minimize the dependencies by having the services layer in the middle. So, whether it's Cache or GT.M and EWD, it is transparent to VistA Novo as long as the service interface remains consistent. The other advantage we see of approach 1 and 2 is that it allows one to expose authoritative business services that are meaningful to the end consumer of the service, while abstracting the intricate details of MUMPS routines.

Thoughts?

Salim

From: robtweed <rtweed@mgateway.com<mailto:rtweed@mgateway.com>>
Date: Friday, November 8, 2013 5:21 AM
To: "VistA Novo: Open Source VistA Developer Toolkit" <vistanovo@groups.osehra.org<mailto:vistanovo@groups.osehra.org>>
Subject: Re: [vistanovo] Relationship between VistA Novo and EWD

This seems like a reasonable summary to me of the approaches available. I'd just clarify that in Figures 2 and 3, it should show the database layer as being GT.M *or* Cache, not just GT.M

That highlights the clear difference between the approaches shown in 1 and 3. The current focus of VistA Novo is completely Cache-dependent and reliant on Cache-specific functionality and interfaces, and only serves the specific requirements of VistA Novo in delivering FHIR services.

Approach 3 is completely generic - it can work at both the VA and in the Open-Source non-VA community, and it makes use of a generic architecture (courtesy of EWD.js) that can support all other VistA-related activity.

My inevitable question would be, other than the fact that approach 1 is probably already under development for the purposes of a VistA Novo/FHIR demonstrator, does it have any long-term justification or viability? Ditto for approach 2, since this is unnecessarily adding an extra set of moving parts and layers that detract from the maintainability and potential performance.

Rob

--
Full post: http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3343

like0

Cache is always an option

Rob Tweed's picture

Yes, there are, for example, many users of Medsphere's VistA system that use Cache.  Whilst many users of VistA outside the VA will choose an fully Open Source stack, there's nothing forcing anyone to *not* use Cache if, for example, they feel that the support services offered by InterSystems are preferable and worth the cost.  It's all about their choice at the end of the day, and maintaining that freedom of choice without adding unnecessary layers of complexity.

To that end, I'm not sure why there has to be any "middle tier" in some other technology - The Node.js environment provided by EWD.js already provides that tier and can do any and all of the work you're envisioning, viz:

"expos[ing] authoritative business services that are meaningful to the end consumer of the service, while abstracting the intricate details of MUMPS routines."

As I keep saying, keep the architecture lean, simple and with as few moving parts as possible, and make full use of the Mumps database you already have at your disposal on the VistA platform.  It has all the capabilities you need as a JSON database.  See:

http://www.mgateway.com/docs/universalNoSQL.pdf

Rob

 

like0

Relationship between VistA Novo and EWD

Salim Semy's picture

Hi Rob,

All good points.

I'll update the figure to reflect a GT.M or Cache back-end in Figures 2 and 3.

The alternative approach you describe below has merit. I think it would be good to highlight the pros and cons of each approach, consider its implications on our approach for VistA Novo, and take it back to the VA as we move forward. I've put a starting point on the wiki, please contribute.

Thanks,
Salim

From: robtweed <rtweed@mgateway.com<mailto:rtweed@mgateway.com>>
Date: Friday, November 8, 2013 12:54 PM
To: "VistA Novo: Open Source VistA Developer Toolkit" <vistanovo@groups.osehra.org<mailto:vistanovo@groups.osehra.org>>
Subject: Re: [vistanovo] Relationship between VistA Novo and EWD

Yes, there are, for example, many users of Medsphere's VistA system that use Cache. Whilst many users of VistA outside the VA will choose an fully Open Source stack, there's nothing forcing anyone to *not* use Cache if, for example, they feel that the support services offered by InterSystems are preferable and worth the cost. It's all about their choice at the end of the day, and maintaining that freedom of choice without adding unnecessary layers of complexity.

To that end, I'm not sure why there has to be any "middle tier" in some other technology - The Node.js environment provided by EWD.js already provides that tier and can do any and all of the work you're envisioning, viz:

"expos[ing] authoritative business services that are meaningful to the end consumer of the service, while abstracting the intricate details of MUMPS routines."

As I keep saying, keep the architecture lean, simple and with as few moving parts as possible, and make full use of the Mumps database you already have at your disposal on the VistA platform. It has all the capabilities you need as a JSON database. See:

http://www.mgateway.com/docs/universalNoSQL.pdf

Rob

--
Full post: http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3343

like0

No Mumps web server needed

Rob Tweed's picture

> You could use Sam Habiel's web server built on top of Virtual Patient Record (VPR) storage  to get the data in a JSON or XML format, > or the FHIR data records directly. 

Agreed that it makes sense to use the VistA platform to act as the data store, but what you suggest doesn't make sense in the context of the EWD.js scenario - ie approach 3.  EWD.js can and should do all of the JSON interfacing you're describing, as it provides a properly secured and proven web service layer in addition to a direct JavaScript function interface.  

A Mumps-based web server is neither required nor desirable when EWD.js is providing the interface to GT.M or Cache.

 

like0

Test Data & Mocking

Christopher Edwards's picture

With Rob's recent developments (http://robtweed.wordpress.com/2013/11/12/ewd-js-for-the-raspberry-pi/) which now provides noDB.js. This is API equivalent with NodeM and GlobalsDB which writes stringified JSON to a text file. While this doesn't seem revolutionary by itself it does build the framework where one could write an EWD.js API/Application and have a mock data store (NoDB.js) which could be easily controlled and verified (did the correct data come through the API, did the correct data get persisted through the API) and could be hooked up to either a GT.M or Caché based VistA installation (or just to M itself). This could prove incredibly helpful not just in vistanovo development but other VistA development efforts.

like0

How EWD.js maps between JSON and Mumps globals/arrays

Rob Tweed's picture

One of the key benefits of EWD.js is its built-in, intuitive and automated mapping between the JSON-centric world of JavaScript and the multi-dimensional Global/array-based world of Mumps.  Just two JavaScript APIs: _getDocument() and _setDocument() do all the work that anyone needs: no need for new Mumps libraries of code, no need for Cache Objects or anything like that.

I've written a new article that explains everything you need to know about JSON-enabling VistA using EWD.js:

http://robtweed.wordpress.com/2013/11/19/json-interfacing-vista-and-other-legacy-mumps-systems/

Perhaps this article will help set the record straight on why we really don't need all the additional, grafted-on technologies that are otherwise assumed to be necessary for VistA modernisation

Rob

 

like0

The Definitive Word on EWD.js and Vista Novo

Rob Tweed's picture

Rather than comment here, I've documented exactly how EWD.js sits with respect to Vista Novo here:

http://robtweed.wordpress.com/2014/01/23/ewd-js-on-fhir/

Rob

 

like0

Relationship between VistA Novo and EWD

Sid T's picture

The Rewards of Running Server Side JavaScript:

http://www.zdnet.com/the-rewards-of-running-server-side-javascript-revea...

On Thu, Jan 23, 2014 at 11:47 AM, robtweed <rtweed@mgateway.com> wrote:

> Rather than comment here, I've documented exactly how EWD.js sits with
> respect to Vista Novo here:
>
> http://robtweed.wordpress.com/2014/01/23/ewd-js-on-fhir/
>
> Rob
>
>
> --
> Full post:
> http://www.osehra.org/content/relationship-between-vista-novo-and-ewd
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3343
>

like0