Purpose of VRRS in a cloud environment
Dennis Ballance
These days there is increasing attention on the idea of the cloud for medical content. With this model, the data resides on the servers of the content provider, and content is linked between different providers. Hence, the medical record for Fluffy could live on one company’s cloud server, and be linked to the telemedicine report on another server. This has several obvious benefits, most particularly that the latest version of the relevant content is always what is accessed, rather than having copies distributed then made obsolete (and having to build a mechanism of updating all extant copies). It also has authentication/permission design challenges, of course.
All of this has raised in my mind the question, “What is the purpose of VRRS in this cloud environment?” After all, if the content is living where it is produced, why do we need a document exchange standard at all? The answer is that even though the data is hosted in various servers, users still want to _view_ the data through a single interface.
When looking at a medical record, for instance, I may want to review the telemedicine report. There are two options here – one is that I click on the report link and it opens a window to another website, with completely different styling and layout, to display the report; another is that I click on the report and the medical record provider fetches the latest data from the telemedicine provider and renders it for me.
This background communication is exactly where VRRS fits in. The medical record provider doesn’t plan to store the data long-term, but still wants to have the data to be able to format and display it. Additionally, there may be a few key data elements it does want to store locally; it can easily parse these out of the document. By virtue of the XML formatting, it is even possible for the medical record provider to design an XSL file that renders the report in a style matching the provider’s website, without even having to parse the incoming document.
Additionally, in the case where the client, or the medical record provider, parts ways with the telemedicine provider, VRRS provides a convenient way to bundle up a handoff of the report content that the client had purchased.
This draft standard can clearly serve an important role in a future cloud-based environment. Hopefully anyone on this list involved in that direction of development will consider implementing VRRS as part of their solution!
--Dennis
Aerik Sylvan
--
You received this message because you are subscribed to the Google Groups "Veterinary Radiology Report Integration Work Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vrrs+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Michael Martin
Very well said Dennis.
Just in case anyone is under any illusions that the HTML transforms I’ve been creating are THE presentation form of the VRRS report, please understand that the only real function of those is to demonstrate that the standardized data CAN be transformed into readable (if ugly in my case) web content. We fully expect developers of medical record software to choose to render the data into a format that is consistent with their internal content. That way the referring veterinarians won’t have to learn to read the report format of every specialist they consult.
Mike
--
Aerik Sylvan
Michael Martin
The standard does provide for references to things like WADO just about any place you would need them. We haven’t populated them well in the examples, and certainly haven’t incorporated that in the rendering transform.