1. Search for a patient by id, name or other demographics (e.g., Gender and DOB).
2. Update the patient record with an alternative identifier used to support authorized access to their health information.
3. View XdsEntry resources and the Documents associated with the selected patient.
4. Enable Authorization and Login using OAuth and OpenID (stretch goal).
I managed 1 & 2, starting this time with absolutely no code. I made no progress on goals 3 and 4. Goal 3 was really not-material to my use case. Goal 4 was simply not possible given the time I had, but I'm going off to my room now to work on that. If I can make progress on that, I'll report about it later.
I had a few challenges with caching of search results, which had to do with my IE settings. That took me at least two hours to work out, and was made more complicated by some code changes which had been posted to one of the servers that broke search. I hadn't planned on using IE as my browser, since I prefer Chrome. However, due to a strange interaction between Chrome with its implementation of XMLHttpRequest and one of the test servers, I couldn't get my solution to work in Chrome. So, I downgraded to IE 8.
What was interesting about this exercise was that all my code was HTML, CSS and JavaScript. I had no need to install a web server, JSP/Servlet engine, XML or XSLT processor, or anything else.
This has huge benefits to integrators. Imagine that you are tasked with creating an ADT record, or updating an admission record in a Health IT system today. What do you need? Let's take a look at this using HL7 V2, V3 and FHIR:
V2
To deal with this in V2, you first need some way to access the ADT record. In V2, you could do this using a control query message, but only if your Health IT solution supports V2 Queries for those types of records. If it doesn't, you'll have to tap into the database.
You'll need to be able to create and send HL7 V2 messages, and receive and parse the responses. Likely that means that you need an interface engine of some sort. You cannot really do this from inside a web page without quite a bit of infrastructure. At the very least, you'd need a signed Active X Control that integrated with your Interface engine. More than likely, you'd be coding pages in the interface engine, or, you'd be running a web server and doing the integration with the interface engine (and the Health IT system that it was connected to) behind the scenes. May interface engines already support generating web pages, and some even launch and work well with a bare-bones server like Jetty.
V3
To deal with this in V3, you will need an XML Parser, and tools to deal with Web Services, like Apache Axis 2. Again, you'll probably need a web server. You'll have to work through a number of integration issues with the V3 messages, including making choices about (or at least configuring) vocabularies that can be used. If you are lucky, your Health IT system will implement the appropriate V3 messages. You may be able to query for the patient record, or you may have to shadow the ADT content by listening to existing messages, or again, you could have to tap into the database.
FHIR
You need a modern web browser that supports XMLHttpRequest. Query is built in for resources, as are the basic operations such as create, update and delete. All of your code can reside in a web page. What is even more significant is that the syntax that you use to access the resources is very much aligned with your programming language so long as there is good JSON support for it. So, if you wanted to access the first patient identifier, it looks like this: thePatient.identifier[0] (taken from the code I wrote this weekend).
Comparing my experience here with experiences in V2, V3 and yes, even CDA, FHIR is clearly the way to move forward.
The FHIR team is already planning the next FHIR Connectathon. We discussed what the focus should be at the next one. One topic of special interest to me was paying attention to documents in FHIR. It should be interesting.
No comments:
Post a Comment