Decades after George

For me, the highlight of the recent WorldVistA meeting at Tempe was meeting George Timson, the man who made FileMan. FileMan is VistA’s core, a network database with a built-in reporting mechanism. As George showed, type the correct sequence at a terminal and you can make any sort of report. Charts? Yes, they’re there. The terminal plots in characters.

At Tempe, I spoke too, showed how FMQL let’s you walk FileMan as linked data. Click, click through a browser and see what’s there. Javascript up what you want. The guys from MedSphere showed much the same thing using SQL Projection. They even linked in a standard SQL reporting tool. George Lily showed how to export a CCR using a custom RPC.

But you know that after all this time, if it’s reports you want, not one of these approaches - Semantic Graph, SQL Projection, custom RPCs - will ever exceed the terminal menus of George’s FileMan, either in scope or ease of use.

All we’re doing is making reports from FileMan “sleeker”, “modern”. Look, no terminal! We’re in a browser. Look, your favorite tool. It’s XML! Not that this isn’t worth while. So often, the medium is the message.

But still, it’s sobering. For all our “advances”, the best way to test any VistA report is to roll and scroll through FileMan. Ok, the terminal shows this - what’s the SPARQL for that? Does it work?

Query or Dump

When PCs became graphical, they adopted a “Desktop motif”. There’s a trash can. You put files in folders. Hit carriage-return. See, it’s what you are used to, just on a screen.

Healthcare’s dominated by documents. Patients are described in mounds of paper. Clinical trials too, mounds of forms. Mounds of paper move around so no surprise that the Document motif dominates standards for its automation.

In these standards, the patient’s information remains in a document - a Continuity of Care Record (CCR) is a document, just electronic, tagged in XML. Clinical trials have Study Data Tabulation Model (SDTM). Don’t worry - forms remain. We just added an X - XForms. Go behind the jargon and, in this motif, monolithic piles persist. In essence, database dumps replace piles of paper.

A patient has a diligent primary care provider with all her information. Then she moves. And the old provider dumps her data on the new provider. Document too big? Maybe there’s a magic way to scrub the dumps so only current or relevant data pours out. Really? Who or what decides relevance?

There is another way. Tried and true. Call it the database motif. You query what you want from a database. In this motif, providers publish, make data available, rather than dumping out all and everything. Based on need, others query for what they want, rather than suck down everything and anything in one go.

Which query mechanism? This site promotes the Semantic Web. You would SPARQL. But perhaps more XML-centric stuff will take hold. Either way, query, read, query, some more. There’s no dump.

Yes, this means care providers must federate. Yes, some way to identify individual patients as they move. But you need such infrastructure no matter what. Whether you dump or query.

Oh woe! Now we’ve lost the precious document! The single point of reference! Well, if you really want the lot then go ahead and query for all and everything and hit print. Still an option. But one hopefully few would take. Think of the planet for heaven’s sake.

More: I’m not talking here to the value of various standards as data models, only the implied mechanism for transmitting modeled data. As CDISC’s roadmap calls for …

The separation of content standards from the means of transporting that content

Using VistA’s extensive, pub-sub HL7

VistA, the biggest Medical Record System in the U.S. wallows in HL7 - its applications publish all conceivable HL7 events, which subscribers, other VistA apps or outsiders, register to get. The mechanism is simple. For each event it publishes, an application registers an event driver protocol with VistA’s HL7 engine. For each event it wants, a subscriber registers with the appropriate event driver. The engine takes events and routes them to appropriate subscribers.

Consider the VistA Radiology/Nucleur Medicine application …

Eight event driver protocols (RA REG, RA REG 2.3, RA EXAMINED, RA EXAMINED 2.3, RA CANCEL, RA CANCEL 2.3, RA RPT and RA RPT 2.3) were exported with VistA Radiology/Nuclear Medicine

Notice these are in pairs, for pre and 2.3 messages. If you prefer, you can keep subscribing to older HL7. VistA’s good this way. It doesn’t deprecate.

And there a VistA release ends, right? Applications register what they publish. Subscribing must be deployment specific, up to an installer, an administrator. True but the VA holds hands …

Six subscriber protocols (RA TCP ORM, RA TALKLINK ORM and RA PSCRIBE ORM and RA TCP ORU, RA TALKLINK ORU and RA PSCRIBE ORU) … All of these protocols are exported purely for convenience; they can be used as subscribers, or they can serve as examples for creating new subscriber protocols.

TALKLINK and P(ower)SCRIBE are application a particular site may have.

But though pre-defined, these illustrations are not registered. Why? Efficiency …

Once subscriber protocols are added, messages will be built and will stack up until the interface is started. … If ever you need to completely disable an interface and want to stop new messages from being created for this interface, simply remove the subscriber protocols from the event driver protocols

Ok. Extensible, comprehensive pub-sub. What’s not to like? Consider this. What are all the event drivers available in a system? What can an application subscribe to? The Hoot72 Mapper needs to know - how else can it sweep up all relevant VistA data?

Um. Docs. Need one nice table. Event Driver, Application, Event, maybe even example subscribers though their format is straightforward. Go to the VistA command line and you can get a complete list …

vista-all-protocols

Now I need to wade through it, make my table. And that’s not the end either. Once we know what is available, how can we know the format and contents of all these events? Where’s that? Is there a machine-processable spec? Um. There the terminal screen again. Looks like I’ll be ploughing screens in the next days.

Room for Open-Source?

2006. Forrester makes a report on Open Source for Health-Care IT. Like most of its ilk, it was a mixed beast. Though they said …

The success of any open source product depends largely on the success of the community of developers who participate in its development

They noted that …

companies, like JBoss and MySQL, control the development community and almost all the code that goes into the product their employees have generated … long-term success will depend on whether potential customers are willing to pay enough for the enhanced functionality and support services so the companies can prosper

Though they recognized …

among the 37 health-care related projects listed at Source-Forge … almost half … dead

They remained optimistic …

Today, however, the open source community in health-care is more energized

But the report has an appendix, listing their newer, vital projects and a quick check shows only MedSphere, a VC-backed corporation, still around.

For all this, one observation still resonates …

National Health Information Network … by all measures, system integration costs … will dwarf the price of software and hardware … investment to build … would be $156 Billion over five years.

Health-IT money, most of it, will go for custom-add-ons, support. Um. What sort of corporation does that suit?

Hoot72, meet HL(O)

A slew of specifications tell the tale, that most of VistA’s internal applications have HL7 interfaces - ADT (Admission/Discharge/Transfer), Labs, Master Patient Index, Radiology. HL7 is no add-on. It is how they talk.

VistA comes with a HL7 Message Router. Well, two. The older HL, the newer HLO (O for Optimized). Each …

provides messaging services and a single toolset for … VistA applications to create, send, receive, and process HL7 messages.

The router focuses on the protocol-piece of a message, the MSH segment. The format of clinical data is an application’s job …

When coding the routine to generate an HL7 message, you are responsible for generating the message body — the set of segments composing the text of the message. You are not responsible for forming the message header, however; this is created and managed for you by VISTA HL7.

Through either, applications can also talk to the outside …

The VistA HL7 package is also used to integrate commercial off-the-shelf (COTS) healthcare applications

So here it is. Hoot72, link to HL(O), make a graph for VistA. Great demo but doable?