DSTU2 prototype #fhir server now up

In preparation for FHIR Connectathon 8 one of the Oridashi Hiasobi servers has been updated to DSTU2. Feel free to check it out on:

    http://demo.oridashi.com.au:8290/

I hope to have the other servers updated to DSTU2 shortly (before Connectathon) and hopefully begin some use of new DSTU2 resource types Appointment, and Schedule.

Send me a message if you find any issues or have suggestions for my DSTU2 server(s) implementation.

#FHIR Enabling Client Side Web Form Automation

Using a #FHIR server from client side Javascript provides a simple and effective way to obtain data from healthcare information systems to allow population of existing forms from local system data or retrieval of FHIR resource based data for submission.  

In this short animation one can see a local clinical information system (left) and a rough and ready browser based web application (right).  On the local machine a FHIR server is running giving access to the current context (patient being viewed in the clinical information system) and providing search to allow the retrieval of data for resources in this case Patient (for administration) and Condition, Procedure, MedicationPrescription, AdverseReaction (for a health summary). 

Here we can see how the web application can access the local record to populate a patient registration form on the client side and also how a health summary can be similarly obtained.  These can then be submitted to the web application - a whole lot more appealing (and accurate) than filling in things by hand! Of course the real benefit comes when there is broad support for FHIR interfacing across multiple suppliers of healthcare information systems. It is a short step from a retro-fit of existing form entry to the server accepting FHIR data and ideally implementing a standardised messaging endpoint (mailbox) or server (create/update).

Accessing the local system health record is achieved using Javascript; with minimal scripting it is possible to populate an existing web form based on data retrieved from the local FHIR server in JSON format. (The current patient id is obtained from another call to the FHIR server for that purpose)

function LoadConsumer() {
        $.ajax({
            url: "http://localhost:8190/Patient/" + patientId + "?format=json",
            type: 'GET',
            success: function (data, status, jqxhr) {
                var text = jqxhr.responseText;
                //$("#output").text(text);
              
                var data = jQuery.parseJSON(text);

                $("#FamilyName").val(data.name[0].family[0]);
           
                $("#GivenName").val(data.name[0].given[0]);

                $("#Sex").val(data.gender.coding[0].code);

                var bits = data.birthDate.split(/[-]/g);
                $("#DateOfBirth").val(bits[2] + '/' + bits[1] + '/' + bits[0]);
            },
            error: function (xhr, ajaxOptions, thrownError) {
                if (thrownError == "")
                    thrownError = "Not responding";
            }
        });
    }

This populates the form (produced from a .NET MVC application):

<form action="/" method="post">
   <table>
      <tr>
         <td>Family Name</td>
         <td>
            <input id="FamilyName" name="FamilyName" type="text" value="" />
         </td>
      </tr>
      <tr>
         <td>Given Name</td>
         <td><input id="GivenName" name="GivenName" type="text" value="" /></td>
      </tr>
      <tr>
         <td>Date of Birth</td>
         <td><input data-val="true" data-val-required="The DateOfBirth field is required." id="DateOfBirth" name="DateOfBirth" type="text" value="" />
         </td>
      </tr>
      <tr>
         <td>Sex</td>
         <td>
            <select id="Sex" name="Sex">
               <option value=""></option>
               <option value="M">Male</option>
               <option value="F">Female</option>
            </select>
         </td>
      </tr>
   </table>
   <button name="Submit" type="submit" value="save">Register</button>
</form>

So that is it.  FHIR server availability on a local systems can enable a generalised automation of population for existing web based forms with some minimal Javascript glue. Give it a try!

Oridashi #FHIR Servers Demo Rework

Revamped site for Oridashi-Hiasobi servers demonstration (+ whole Oridashi site) is now up and running.

Check out fhir.oridashi.com.au for live demonstrator calling Oridashi-Hiasobi servers direct with Javascript from the page. This includes:

• ability to set xml or json return formats
• has a set of samples searches
• results of search are loaded on screen.
• click 'See MD' or 'See BP' to switch between servers

Of course the base demo servers are still available for direct use.

Let me know if there are any issues.

#FHIR Connectathon 6 + population metrics

Population metrics play app for HL7 FHIR Connectathon 6 is now online http://demo.oridashi.com.au:8200/fhirpop - feel free to have a play; if you would like your server added let me know the details.

It lets you pick one of 8 online demo servers from the FHIR implementers' community (on the right) and then obtain a population metric chart for that repository.  e.g

Demographics Chart - sex/age breakdown

 Disease Prevalence - top 10 most common current disease conditions

Smoking Status - population stats on cigarette smoking records

There is also a little 'Search by Name' page for any of the servers (link top right).

#FHIR Cook until Tender

Long time no post - product perspective takes hold.  As FHIR reaches DSTU commercial reality comes into play.  From the start I have been looking at FHIR as an implementation solution to provide a building block in solving the need for a common access model for primary care systems in Australia - Hiasobi is my product to achieve that.

Business tenders come across my plate every so often that need a solution to data access in a way that works well for integrators without the major effort of corporate wooing of mostly disinterested clinical system vendors. Based on previous escapades in providing interfacing for primary care systems with CDA and VMR for various projects including connecting to the national PCEHR (Personally Controlled Electronic Health Record), point-to-point messaging and decision support services it has all come to this point - "need for cost-effective integration products".

Nothing like responding to a tender request to really clarify what you do and don't do and what a prospective customer might actually need.  A few things really stand out in my mind with the process of presenting FHIR as the basis of a solution.

a) "There are the specs - go ahead and read them" - the specification is open, I can give folks the URL and say take a look.  No 3 day course on the RIM, I don't need to hold their hand  - they can read it and understand it; even folks that don't really know what HL7 and standards are about.
b) "Phew DSTU" - those 4 letters make a great deal of difference, it is a draft standard for trial use i.e. good enough to use in anger and locked in enough to rely on.  Ever won a tender with 'it should be a DSTU soon' - it makes me nervous as change with a live customer is costly.
c) "FHIR Community - you're in it" - Using FHIR brings you into an active and friendly implementer crowd; they happen to also be a 'standards' crowd, but really these folks are the ones making it work rather than talking about how we might make it work.  It is also quite appealing doing this in Melbourne -"oh yeah, the guy that kicked off all this FHIR stuff is a bit north of town".  I can't help being lucky - Melbourne is a nice place to live; I recommend it for anyone keen on FHIR ;)

"Hiasobi" (General Practice FHIR Suite) is now an active product:

• Demo Servers (still up) - http://www.fhir.oridashi.com.au/
• Hiasobi Information Wiki - http://www.fhir.oridashi.com.au/wiki/Main_Page

If you would like to talk FHIR with Australian primary care systems contact me email brett.esler@oridashi.com.au or skype brett.esler - "free the data"

#FHIR towards DSTU

Happy new year.

As we kick off 2014 the FHIR standards have moved to the DSTU candidate version 0.12.

My public services have been updated to align with changes; If you do decide to play let me know if you find any holes with my v0.12 updates.

As part of the updates in this round some more features have been added these include:

Deleted resource in history atom feed
In the system history bundle deletion is now supported.  This allows resources that have been deleted to be represented in the history feed.  For example deletion of a Condition resource:

<deleted-entry xmlns="http://purl.org/atompub/tombstones/1.0"
  ref="http://localhost:8190/condition/253" when="2013-12-02T12:36:04Z" />

This allows synchronisation of resources using atom based pub/sub as per function HL7 EHR Functional Model IN 2.3 Synchronization.

Metadata includes supported search-type elements
Some improvements also have been made to the metadata call which returns a server's conformance statement as a conformance resource instance.  This now includes all standard search parameters supported for each resource.  For example for the Condition resource the _id, code, subject and status search parameters are supported:

<resource>
      <type value="Condition" />
      <operation>
        <code value="read" />
      </operation>
      <operation>
        <code value="search-type" />
      </operation>
      <readHistory value="false" />
      <searchInclude value="Condition.subject" />
      <searchParam>
        <name value="_id" />
        <type value="token" />
      </searchParam>
      <searchParam>
        <name value="code" />
        <type value="token" />
      </searchParam>
      <searchParam>
        <name value="subject" />
        <type value="reference" />
      </searchParam>
      <searchParam>
        <name value="status" />
        <type value="token" />
      </searchParam>
 </resource>

Along with these new search parameter definitions there are other resource level conformance definitions:

• Resource level operations supported (operation) are in this case read (read the current state of the resource), and search-type (search the resource type based on some filter criteria).
• Currently readHistory is not supported for a specific resource type - as indicated  

    <readHistory value="false" /> 

  this will soon be implemented ;) allowing a by-resource history feed.
• There is also a searchInclude element specified which defines which resources associated with this type may be included on a search. For Condition resource the subject (Patient) can be included with the _include search parameter.

Profiles are next - to define details of terminology bindings and extension definitions.

Extensions to Patient resource
As part of my scope of interest a couple of resource extensions have been added:
- ethnicity:  commonly implemented Australian administrative coding of aboriginality; from National Health Data Dictionary
- age: useful value when my server is switched to 'de-identified' mode; no specific date of birth supplied (no names and person identifiers either) e.g.

        <extension url="http://oridashi.com.au/fhir/extension/age">
          <valueQuantity>
            <value value="10" />
            <units value="a" />
          </valueQuantity>
        </extension>
        <extension url="http://oridashi.com.au/fhir/extension/ethnicity">
          <valueCoding>
            <system value="http://oridashi.com.au/system/nhdd/ethnicity" />
            <code value="1" />
            <display value="Aboriginal" />
          </valueCoding>
        </extension>

These will be the subject of my conformance profile definitions in the near future.

Server 3 'zedmed' cis languishes a little behind resource content wise but can be accessed on demo.oridashi.com.au:8192 if you dare.

Servers launch page has been updated to 0.12 also going through a set of basic read and search examples.

Until next time free the data

#FHIR Connectathon 4.5

At the end of last month it was my great pleasure to attend the IHIC 2013 FHIR Connectathon - out of cycle, this took place in Sydney Australia.  This was the first FHIR connectathon I have attended in person and it was both great fun and also a great learning experience.  The benefits of working on implementations with a group of folks ready to discuss and explore issues is incredibly rewarding both in benefits to my implementations but also the community building that carries on beyond the event itself.

With a large Australian showing there were a number of participants that came to the connectathon with their own systems or even a blank slate and some preliminary reading and left with working implementations communicating with other participants.

I was working on my GP wrapper services and along with Grahame Grieve's server and pub/sub tools reached the point of automatic submissions to the HL7Connect server based on the clinical system record FHIR history.  Some real progress in a short space of time.

The other thing I was playing with were some basic population health metrics collected and processed by connection to existing FHIR servers. This use without any specific point-to-point arrangements made with the server vendors.  Here are some samples for 7 servers all with demographics charts and  a couple with smoking status.

Definitely the (geeky) highlight was the demo of Brian Postlethwaite's (DCA) windows phone application searching for patients and providing summaries across multiple FHIR servers.  Phil Wilford's (NEHTA) live adhoc update of his patient details with his newly crafted FHIR client and being able to see changes on the windows phone was met by spontaneous applause.  This is the stuff that old integration folks appreciate, it just works, I just saw it work....

Ballot resolutions to deal with for the next connectathon - should be fun; no really; I am looking forward to it.

FHIR free the data...