Since we had only three weeks from defining and assinging the individual tasks to our showcase deadline, we had to strip away some of the complexities from handling the FHIR Patient resource we had focused on.
For example, we did not work with any extensions nor did we pay much attention to the narrative text within the resource. Instead I asked the students to create short presentations on these topics and present them at the showcase so everyone can take home the knowledge even if we didn't touch them in depth during implementation.
Every team also gave a short walk-through of their implementation/deployment process and offered feedback of where the major problems and questions arose. Those were the issues I was especially interested in so I can take these into consideration when planning next semester's course.
After lunch break we set up a WiFi network connecting
- Cloverleaf (running the student's translations between V2 and FHIR and processing the created test data),
- a locally deployed FHIRbase server running in a VirtualBox with JSON based PostGres database
- a Java FHIR client application developed from scratch based on the HAPI FHIR api
After only a few minutes of reconfiguration to the newly assigned IPs and the recognition of the fact that host name resolution wasn't my WiFi router's strongest suit, to everybody's surprise:
Just like that.
At first I couldn't believe it. My 10 years of experience working in IT have tought me that
NOTHING EVER JUST WORKS.
Especially not in a scenario that involves a WiFi network and my crappy old router
Especially not when hosts running different operating systems are involved
Especially not if the server application runs in a virtual machine
There's always a firewall acting up
There's always a port blocked, a validation not passed or a connection dropped
I think anyone who ever wasted hours and hours of precious life time trying to set up a home network can relate to this.
But as it seems, Murphy's law was deferred on Friday afternoon.
There was no arguing the fact that the same patient "Hans Müller" Cloverleaf picked up from the HL7 V2 message could be found in the FHIR server's database having made the transformation from pipe-separated hierarchical record format to XML, riding the WiFi waves from Cloverleaf's RESTful Client protocol adaptor to our FHIR server's URL, where he was once again remodeled from XML to JSON and finally laid to rest in the PostGres database.
But no napping time for Hans Müller since the Java Client application queried the server for a list of all patients and our patient was quickly retrieved an found himself in the application's UI patient table where he was being prodded by the editing feature and once again sent on a journey back to the server.
Again no time to rest because the next RESTful query was sent to the server, this time from Cloverleaf, anxious to translate our Hans Müller back to his original shape, a HL7 V2 message.
We were so excited, we decided to ignore the minor flaw that our Patient had turned into a Hans M?ller in the client application, but was restored to his original name when he arrived back in the HL7 message.
In Germany we are used to pain when it comes to Umlauts.
("Schei? encoding", as we say)
I am very happy that the student's hard work paid off. I think we have successfully proven that FHIR stands up to it's claim of being accessible and quick to implement.
Dear students: you're awesome! Thank you for making this happen!