RE: [architecture] RE: [EXTERNAL] [architecture] Mapping VistA data to FHIR...







Helga,

Drew,
Charles,
Comments?
Tnx.
PT





Sent with BlackBerry Work

(www.blackberry.com)


From: Doug rosendale <doug@rosendale.us>
Date: Tuesday, Feb 26, 2019, 12:36 PM
Cc: Douglas E. Rosendale <drosendale@Deloitte.com>
Subject: Re: [architecture] RE: [EXTERNAL] [architecture] Mapping VistA data to FHIR...


I understand that the VA API’s recently announced are to the CDW.  I have always been curious how API’s to the CDW “relational” store compares to the potential API’s directly to VistA (hierarchical)?  Particularly since  data gets to CDW using Cache.  Appears
there is significant dependency on “Intersystems” either way?  Which is fine.  My questions are routed in timeliness, performance, and data integrity.  If we are looking at patient centric technology for Care Coordination, these factors matter.  


douglas rosendale



On Feb 26, 2019, at 8:56 AM, Peter Li <lip@osehra.org> wrote:


Hi Jason,

Do you know who at VA this leading the mapping effort?  OSEHRA will be setting up a new group - FHIR on VistA next month that plans to develop an open source FHIR v4 interface for VistA.  It would be great if we can get VA to share this information,
i.e., technical documentation with the open source community.  We plan to implement the full Argonaut profile.

Thanks,

Peter

--

Full post:
https://www.osehra.org/post/re-external-architecture-mapping-vista-data-fhir-within-healthshare


Manage my subscriptions: https://www.osehra.org/groups

Unsubscribe from "Architecture Work Group" Group:
https://www.osehra.org/group/node/2951/unsubscribe



like0

Comments

VistA vs Performance vs FHIR

William Cerniuk's picture

When we used MDWS to access the VistA systems via RPCS (as direct as it gets), there was always the concern that significant access to the VistA system would cause performance issues (outages) for the clinicans using the VistA systems. MDWS just exposed VistA RPCS as a more consumable SOAP model.

The VA Health API backend currently accesses CDW to ensure that no VistA systems are impeded by what could be 100's of thousands of requests for data from Veterans with iPhones per day.  While CDW is "read only" and collects data from the VistA systesm every 24 hours on a cycle, it represents a safe first step in getting VistA data for the Veteran's consumption.

The beauty of a fully isolated layered system is that the data model can change behind the API and the API consumer will never know.  Today it accesses CDW, tomorrow it can access VistA (with special considerations), then perhaps in the future... Cerner.

But as far as relational database, vs flat file, vs indexed files, or otherwise, it is not terribly important how the data is stored behind the API as long as the sanctity of the API is respected and the peformance of the data retrieval is adequate for the task.

To understand the model, it is important to see the solution in action and understand the user experience of the Apple Health mobile app. The Health app is very forgiving of the API's performance.

like0

Excellent point - it all

Peter Li's picture

Excellent point - it all depends on the use case.  For Veteran's consumption, timeliness is not as critical, so using the CDW to serve the patient data behind the VA Health API make sense.  While in the case of Dr. Rosendale's comment, he is looking at the VA Health API in the context of clinical Care Coordination, and VA Health API may not work due to timeliness issue. 

I agree that the VA Health API can be used by the Veteran-facing or clinician-facing applications; however, I believed for many of the clinical applications that needed higher performance, the VDIF (Veteran Data Integration and Federation) will be the point of access for the FHIR API.

like0

RE: [architecture] RE: [EXTERNAL] [architecture] Mapping...

Jack Taylor's picture

A moment of Philosophy 

The thread is compelling to all in the audience but I like to deal in the middle ground of who we serve. 
1. The Patients 
2. The providers (doctors are not with patients 7x24 so we need broader scope).
3. What we have now - I for example can review my records, schedule appointments, submit personal data (to VA) etc. all through MyHealthevet premium at no cost. 
4. I already have the Apple Health App on my phone and other (less elegant) solutions are sprouting. 
5. We all have to deal scrupulously with the Rules and the tyranny of government budgets!

Regardless I say Press On!


Sent from iPhone 6 
Jack T
703-626-5182

On Mar 5, 2019, at 8:13 AM, "architecture@groups.osehra.org" <architecture@groups.osehra.org> wrote:

Excellent point - it all depends on the use case.  For Veteran's consumption, timeliness is not as critical, so using the CDW to serve the patient data behind the VA Health API make sense.  While in the case of Dr. Rosendale's comment, he is looking at the VA Health API in the context of clinical Care Coordination, and VA Health API may not work due to timeliness issue. 

I agree that the VA Health API can be used by the Veteran-facing or clinician-facing applications; however, I believed for many of the clinical applications that needed higher performance, the VDIF (Veteran Data Integration and Federation) will be the point of access for the FHIR API.

--
Full post: https://www.osehra.org/post/re-architecture-re-external-architecture-mapping-vista-data-fhir-0
Manage my subscriptions: https://www.osehra.org/groups
Unsubscribe from "Architecture Work Group" Group: https://www.osehra.org/group/node/2951/unsubscribe

like0