FHIR / PIX Interoperability

Well, its been a while since I’ve written about FHIR, and after lots of interesting exercises in trying figure out “where that goes” I have a working FHIR interface on the Client Registry. I’d thought about sharing some of the interesting use cases I’ve been able to test, and which I hope can be demonstrated at the FHIR CAT this weekend.

FHIR Registration with PIX Registration to XDS Registry

This was the first use case I tested. Basically registering a simple patient record via a POST to http://cr.marc-hi.ca:8080/fhir/0.11/Patient results in an ITI-44 to our XDS registry. This allows an iPad app to create a patient which is then propagated to an affinity domain (i.e. you can have FHIR interface notify another PIX manager)

FHIR Query of an ADT (ITI-8) Registration from an HIS

The second demonstration that I’ve tried is sending an ADT^A01 to the PIX manager and retrieving that data using the FHIR query. I’ve also been able to update the information via FHIR and retrieve the changes via a QBP^Q22 message.

Additionally, the business logic of a client registry (auto/manual-merging, fuzzy matching, auditing, etc.) triggered on the FHIR interface as well.

I’ll post more updates as they are available. Our plan is to take the software to the FHIR CAT and the IHE CAT in January. FHIR may be useful in mobile IHE profiles and this provides a good POC and can identify gaps (it is great to see how a system like this might behave).

Interfaces are available publicly:

FHIR: http://cr.marc-hi.ca:8080/fhir/0.11/
PDQ/PIX Version 2: llp://cr.marc-hi.ca:2100
PIXv3: http://cr.marc-hi.ca:8080/PIXManager
PDQv3: http://cr.marc-hi.ca:8080/PDQSupplier
HL7v3 (CA): http://cr.marc-hi.ca:8080/cr

Extending Code Lists in Everest

Someone asked a really great question on the Everest forums. I am paraphrasing but the gist of the question was: “How do I add a code to an enumerated vocabulary?”. In order to answer the question I’ll dive a little into how Everest generates code lists.

When generating the RMIM assemblies, GPMR will parse the vocabulary MIF files and keep an internal representation of the value sets, code systems and concept domains that properties are bound to. When generating C# or Java GPMR will determine the best way of representing the value set in code.

• If the Value Set or Code System is not complete (i.e. is marked partial) then any properties bound to said value set carry a type of CS<String>, CV<String>, etc.
• If the property or Value Set is marked CWE (extensions allowed) then the the property is bound to String as well.
• If the Value Set is made up of an expression and not all expression components can be found (i.e. intersect X and Y where Y is not available) then the property is bound to String
• Otherwise, enumerate the literals in the value set and bind the property to an Enumeration (or IEnumeratedVocabulary in Java)

That last bit is usually the sticky point. Some jurisdictions ignore the CWE strength and add codes of their own (I have seen custom realm codes, custom null flavors, all kinds of weirdness in our travels).

In order to overcome this Everest (and jEverest) provide a relatively easy mechanism for assigning “non standard” codes to properties. For this example, let’s say we want to assign a custom ProcessingID of “Sample” (a bit contrived but it illustrates the process). To assign our ProcessingID of “S” we’d do this in .NET:

PRPA_IN101103CA sample = new PRPA_IN101103CA();
sample.ProcessingCode = Util.Convert<CS<ProcessingID>>("S");

In Java the process is a little easier as jEverest uses IEnumeratedVocabulary so we can just add the code:

PRPA_IN101103CA sample = new PRPA_IN101103CA();
sample.setProcessingCode(new ProcessingID("S", null));

The result is a (non standard) XML instance carrying our custom code:

<processingCode code=”S”/>