FMQL is hosted under the grand title, Semantic VistA. Why Semantic? It’s not because we based FMQL on SPARQL, the SQL-like query language of the Semantic Web. No, FMQL is a semantic query mechanism because it distinguishes between references to medical concepts and to other patient data. With this capability, it supports simple but powerful patient-data retrieval. Without it, FMQL clients – or patient-data crawlers as I’ll call them here – would be bloated and a lot more difficult to maintain.

Enough generalization: look at this patient allergy record in VistA. A crawler would fetch this allergy with a simple DESCRIBE and back would come JSON with lot’s of dates and strings and URIs. I’m going to focus on two URIs in the data …

  "gmr_allergy": {
      ...
      "value": "120_82-6",
      "type": "uri",
      "label": "GMR ALLERGIES/STRAWBERRIES",
      "sameAs": "VA:4637360",
      "sameAsLabel": "STRAWBERRIES"
   },
   ...
   "originator": {
      ...
      "value": "200-10",
      "type": "uri",
      "label": "NEW PERSON/SMITH,JOHN"
   },

gmr_allergy identifies the allergin; originator identifies who first noted the allergy. Both are URIs – their type says so – and both have labels which enables printing or a graphical client but right now, we don’t care about such cosmetics.

All URIs identify and reference but not all are of the same kind. Here gmr_allergy points to a concept for Substances while originator identifies a person. In a simple “query-anything” mechanism, these would look the same but look at what FMQL has added to the allergin …

      "sameAs": "VA:4637360",

This declaration says that the local identifier 120_82-6 has the same (meaning) as VA:4637360, a VA national concept.

Ah hah, a crawler can say, this URI identifies a concept and what’s more I can ignore this local reference and concentrate on the national VA concept it is equivalent to. After all, patient-data portability depends on standard and national identifiers.

But things don’t stop there. If the Crawler knows of a SPARQL endpoint that declares VA national concepts such as datasets.caregraf.org/va then it may decide to crawl on. It could issue some SPARQL to that endpoint and back will come more JSON with this line …

    "http://www.w3.org/2004/02/skos/core#closeMatch" : [
          { "value" : "http://datasets.caregraf.org/snomed/102261002", "type" : "uri" }
    ],

which says that our concept VA:4637360 has a close match, 102261002 in the SNOMED concept scheme.

I’m getting link-itis here but you get the idea – once FMQL exposes that a URI is to a local, VistA-resident concept and links it out to a standard equivalent, then a crawler is off-to-the-races. This little exercise would lead to these statements …

:allergin <http://vista.caregraf.org/data/120_82-6>, // VistA's id for Strawberries (Allergin)
              <http://datasets.caregraf.org/va/4637360>, // VA id for the same thing
              <http://datasets.caregraf.org/snomed/102261002> . // SNOMED (close to) the same thing

But what about local-only concepts – the keyword “LOCAL” in this list shows what happens to them. And standard concepts? Just look at some ICD 9.

So there you have it. FMQL is a semantic query language because it knows a medical concept when it sees it and through that, its clients can be simple, dumb even, and yet create comprehensive descriptions of patient-care.