Medical Domain Web Services (MDWS)

1. Presentation to World VistA January 18, 2013 Joel Mewton U.S. Department of Veterans Affairs (VA) Medical Domain Web Services(MDWS)

2. 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. * Klingon for: “Speaking the same language”. I am not a Trekkie.

3. In the beginning… CPRS RPC Broker VistA RPC • 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.

4. 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.

5. And Joe said, “Let there be VistAWeb” VistA Web MDO VistA RPC 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.

6. 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.

7. 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.

8. MDO + Web Services = MDWS MDWS MDO VistA VistA • Web services are a well understood, widely supported, modern, flexible, scalable, drink kool-aid 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.

9. 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.

11. 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.

12. 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: 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.

13. Current MDWS Data Sources VistA VistA VistA • 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. CDW VADIR Geographic HDR MHV Active Directory

14. 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

15. Questions? • Internet Resources: • http://mdws.vainnovation.us/mdws2/EmrSvc.asmx • http://mdws.vainnovation.us/MdwsDemo • http://www.va.gov/vdl/application.asp?appid=192