(MDWS)
Presentation to World VistA
January 18, 2013
Joel Mewton
U.S. Department of Veterans Affairs (VA)
VETERANS HEALTH ADMINISTRATION
Jatlh rap hol…*
•
•
•
•
•
•
•
•
•
•
•
•
TLA – Three Letter Acronym. Irony intended. The VA loves to toss these around. Just bracing you…
MDWS – Pronounced “meadows”. VA product for accessing disparate data sources.
VistA – What we call our MUMPS databases. MDWS can and does communicate with other data sources. It’s built to. We’re
going to focus on VistA for obvious reasons.
Web Services – Industry standard, widely supported technology for exchanging data between systems. MDWS is made up of
SOAP web services.
SOAP – Simple Object Access Protocol. One of the two primary ways web services are exposed. MDWS is currently SOAP
web services.
REST – Representational State Transfer. The second of those ways.
RPC – Remote Procedure Call. This is the way CPRS communicates with VistA. The CPRS RPC broker is written in Delphi.
MUMPS – Contagious disease. Also, the language of VistA. Origins (of the programming language) date to the 70s! We’ll
probably just refer to this as “M”.
Local Site – We use this terminology to refer to a user’s home site. Typically the user will have A/V (access and verify –
basically a fancy label for username/password) codes at this site.
Remote Site – Any of the other 130ish+ sites that is not a user’s home site. We typically refer to this in the context of a
patient. So, a patient might have some records at a user’s home site while that same patient might have also visited a
number of other VA hospitals and have records at those remote sites. Providers obviously have a need to view this remote
data when making decisions about patient care.
Design patterns – The way wise geeks write software. Take a look at a recurring task/problem and try to find an extensible
and flexible way to tackle it.
Business Rule – Fancy way of mentioning the way something should work. Concrete VA example: patient sensitivity bulletins.
E.g. if a patient is also a VA employee and attempts to view his/her own records, the RPC “DG SENSITIVE RECORD BULLETIN”
should be executed with the appropriate level argument. MDWS handles things like this automatically.
VETERANS HEALTH ADMINISTRATION
* Klingon for: “Speaking the same language”. I am not a Trekkie.
In the beginning…
CPRS
•
•
•
•
•
•
RPC
Broker
RPC
VistA
Some smart docs in Massachusetts created MUMPS. They saw that it was good.
Ok, too far back. Our story really starts with with CPRS and the RPC broker. CPRS is your
classic “two-tier” application – a GUI that talks to a database. The GUI is the CPRS user
interface and the database is VistA. Note there’s only one VistA here.
The RPC broker is fast! RPCs are basically M routines exposed for remote use via the REMOTE
PROCEDURE file.
Works great for what it is. Used thousands of times every day across VA. Not so great for
reusability…
Remember that leading comment about “one VistA” – CPRS is inherently a single site
application. While the capability does exist to retrieve data from remote sites, it’s quite
kludgy and non-intuitive. For example, to view remote data a user must know to click the
“Reports” tab in CPRS…
That RPC broker is only available as a COM object.
VETERANS HEALTH ADMINISTRATION
RPCs are the bees knees
•
•
•
•
•
Remember: RPCs are native M code. In most cases, they’re written for speed. That makes
them double snappy.
RPCs aren’t just data. VA has years and decades even of business intelligence built in to the
RPCs.
RPCs were and still are ahead of their time. Much of the industry is still stuck with direct
database calls.
Most MDWS calls use the same RPCs that CPRS uses. This means that performance is similar
and the results are usually identical. This makes transitioning to a new app straightforward
for the users. Someone once told me that’s who we write applications for, you know.
VA providers are very familiar with CPRS. Most conversations for new MDWS functionality or
MDWS based tools start with CPRS.
VETERANS HEALTH ADMINISTRATION
And Joe said, “Let there be VistAWeb”
VistA
Web
•
•
•
•
•
MDO
RPC
VistA
VistA
VistA
Who’s Joe, you ask? Joe Gillon. Original author of MDWS and VistAWeb. The man, if you will.
Currently retired and not missing VA. Ok, on with the story…
VistAWeb – A web based GUI for accessing patient data. VistAWeb has its own version of the
RPC broker but written in C#. The underlying communication appears the same to a VistA site
though – it’s all RPCs coming in.
VistAWeb is inherently multi-site. Want a patient’s meds? You automatically get them from
every site the patient has visited – local and remote. All in an integrated view.
VistAWeb communicates directly with remote sites. The same RPCs that are executed at the
local site are executed remotely.
MDO is available as a DLL.
VETERANS HEALTH ADMINISTRATION
MDO
•
•
•
•
MDO = Medical Domain Objects.
Based on the “data access object” (DAO)
design pattern.
We don’t want client applications of
MDO to care about the domain model of
each crazy little disparate data source
and how to interact with that data
source.
Ask for a patient’s vitals once – MDO
figures out how to interact with each of
the different data sources, query and
assemble the results so that one single
type of VitalSign object is returned.
VETERANS HEALTH ADMINISTRATION
Still living in a 2-tier world 
•
•
•
MDO is really only available as a DLL. While an improvement over a COM object, only
technical folks can use it. Also, only developers writing in a language that can consume a DLL.
MDO doesn’t put a ton of smarts around the data. It doesn’t much care about business rules.
Those are left to the database to enforce. Sometime that’s ok but not usually…
In VA, the CPRS source code contains the business rules for interacting with VistA. That
means every new application written that uses MDO would need to figure those out by
reverse engineering that CPRS source code.
VETERANS HEALTH ADMINISTRATION
MDO + Web Services = MDWS
MDWS
•
•
•
•
•
MDO
VistA
VistA
Web services are a well understood, widely supported, modern, flexible, scalable, drink koolaid now, etc. etc. way to expose data and functionality.
MDWS is simply a thin web service layer plopped on top of MDO.
The web service layer serves as a convenient holding location for some of those business
rules we mentioned.
Web services encapsulate a great deal of business intelligence in simple, easy to use
functions enabling developers to write applications rapidly and safely. Developers can worry
about their app and not the data.
MDWS, currently, is SOAP web services.
VETERANS HEALTH ADMINISTRATION
SOAP
•
•
•
•
•
•
•
Makes you smell nice.
Also makes it sooo easy to write a web service client.
All major programming languages have tools to turn a SOAP web service’s WSDL (“wizzdle” –
web services definition language) document in to code.
Client applications developers can literally start writing an app against MDWS in a few
minutes. The developer never even sees the XML! It’s all handled automagically by the code
generated from that development language’s WSDL -> whatever tool.
Client application developer sees a MDWS web service call, “getAllMeds” - when invoked, it
simply returns an object TaggedMedicationArrays that has properties such as name, id, sig,
startDate, stopDate, etc. etc.
Even tools such as Microsoft Office products can consume a web service. Our developer no
longer really even needs to be a “developer”.
MDWS empowers anyone with a good idea to make an app that safely and efficiently can
access the patient’s complete medical record. Or, even other types of data.
VETERANS HEALTH ADMINISTRATION
WSDL
This is a WSDL document. Java, .NET, Ruby, Python, Javascript, C++, the list goes on and on, all have tools
to turn this document into code. What one ends up with is super easy to use “objects” that tell your
application exactly what the API arguments are, what to expect as a response, etc. All without needing to
know (mostly) your app is even talking to a VistA (or whatever) database.
VETERANS HEALTH ADMINISTRATION
MDWS
This is from a MDWS demo project freely
available to anyone. It shows how to write
a MDWS client app. With error handling,
this file clocks in ~160 lines. It contains all
the code required to:
1.
2.
3.
4.
5.
6.
Connect to any VistA site
Authenticate your user using VistA
credentials
Search for a patient
Select the patient
Connect to the patient’s remote sites
Retrieve the patient’s medications
from every VA site the patient has
records
The point is to show writing applications
against VistA is really, really easy.
VETERANS HEALTH ADMINISTRATION
Current MDWS Data Sources
•
•
•
•
•
•
•
MDWS communicates with all production VistA sites.
MDWS can access longitudinal data from CDW to support things like
decision support.
MDWS retrieved MOS (Military Occupation Service) codes from the
VADIR repository. These are available in a Blue Button download.
MDWS exposes some geographic databases for things like finding the
nearest medical facility.
MDWS communicates with the HDR via web service calls.
MDWS extends the Secure Messaging (SM) infrastructure of MHV for
our upcoming release of some mobile applications.
MDWS is a data glutton. It can speak any protocol.
VistA
VistA
VistA
CDW
VADIR
Geographic
HDR
MHV
VETERANS HEALTH ADMINISTRATION
Active
Directory
A few current big-name MDWS Clients
•
•
•
•
•
•
MyHealtheVet
VPS Kiosk (in test)
NUMI (Utilization Management)
Suicide and Homeless Hotlines
TBI (Traumatic Brain Injury)
Many new mobile apps are being written as MDWS clients
VETERANS HEALTH ADMINISTRATION
Questions?
Internet Resources:
• http://mdws.vainnovation.us/mdws2/EmrSvc.asmx
• http://mdws.vainnovation.us/MdwsDemo
• http://www.va.gov/vdl/application.asp?appid=192
VETERANS HEALTH ADMINISTRATION