fmql

VOLDEMORT V1.0.0 for 2012

Christmas is coming and the project saddled with the world's longest acronym has reached its first version milestone. V1.0.0 of VOLDEMORT is now on GitHub along with all its code and documentation. 

V1.0.0 uses the latest OSEHRA FOIA as the baseline or "GOLD" VistA against which it compares others. The release not only distinguishes schema differences between VistAs - old, novel, common, to be deleted, refashioned - it also notes corruption in VistA data dictionaries. 

Some links:

FileMan - self describing, data-wise

Context: been mailing with Sam about a code convergence call and here are some data-centric FileMan issues I'd like to bring up.

All in all, I'd like FileMan to be fully self-describing and enforcing so that its data is easier to model and mine. I don't want to have to do ANY data rework in an outside data store.

1. the three types of multiple: we need to distinguish/define these formally

VOLDEMORT - the first code

This coming Monday, the first code should post on OSEHRA's about-to-be-created VOLDEMORT ("longest acronym ever") GIT repository. The focus for the first pass is FileMan schema comparison, in particular how does a particular VistA's schema differ from that of a GOLD VistA. What is "GOLD"? For now, it's FOIA until the VA stamps a set of files and code as the VOLDEMORT GOLD master.

Now 3 standard output formats for any VistA data and "Linked Data" too

For a while now, you've been able to extract any data - Patient, Institution, Knowhow or System - from any VistA using FMQL, the FileMan Query Language. Open source FMQL projects FileMan as a "web of data" - it's based on SPARQL, the w3c's semantic web language - and to it, data is just data with all of VistA's 2500+ files treated the same way. This contrasts with the myriad of "data type specific" extractors VistA supports today. I'd just like to point out two upgrades in progress. Not just JSON - RDF and HTML too

Semantic VistA: Analytics to support VistA Data Insertion

I've gathered the VistA Analytics reports Caregraf's built up and put them into a Semantic VistA "Analytics Corner". I think some may be useful for the Architecture effort. Most were focused on analyzing VistA's Data and Schema to drive patient, setup and VistA know-how extraction using FMQL; the latest were done as part of OSEHRA's convergence effort. The next push will be information to fully support graph/data insertion, a logical follow-on to full data extraction.

Convergence and HL7

Prompted by Peter Li on the Architecture group, I dug up some old "HL7 in VistA" reports I had - it was done on OpenVistA with a "pre-FMQL" VistA data scrapper (the initial idea for VistA patient extraction was "listen to HL7" and so there are reports. Then when that proved too hard/inadequate, FMQL was made). Most of it isn't of use for convergence but some is. The addition of interfacing of outside systems to VistA starts with HL7 extensions. For example:
Subscribe to RSS - fmql