FHIR Organization

FHIR Organization added - not too exciting there is only one....

http://demo.oridashi.com.au:8190/organization/@1

FHIR Patient

FHIR patient admin details are fleshing out now with support for identifiers, address, phone and email.

This basically involves filling in a number of FHIR datatypes with appropriate content.

The FHIR Identifier datatype still has a kind of equivalence to II in HLV3 datatypes, now 'system' and 'id'.  'system' (like to 'root' in V3 II)  allows the declaration of a namespace using a URI so this supports:

• OID as a namespace for 'id'  e.g. urn:oid:2.16.840.1.113883.16.4.3.2.5
• UUID as a namespace for 'id' e.g. urn:uuid:76d9bbf-f293-4fb7-ad4c-2851cac77162
• "urn:ietf:rfc:3986"  - states that 'id' value will be a URI, complete id
• Custom URN namespace e.g. http://www.acmehosp.com/patients
• 'Managed' URN namespaces, HL7 controlled see: Identifier Systems

This gels together a number of common identifier namespace/system method into a workable solution.  

The 'id' value (like 'extension' in V3 II)  is the actual identifier - some processing is simplified as now even globally unique values are stored in 'id' when 'urn:ietf:rfc:3986' is used as the 'system'.   This seems easier than the V3 datatype II way of checking if 'extension' exists before you know whether  'root' is a namespace or a globally unique id itself.  

The other obvious thing of note is the inclusion of the 'period' element which allows start and end time of the identifier to be included.  This helps represent common 'human identifiers' where you likely have a card or such defining your id.  This probably has an issue date and an expiry date so useful to define the currency of the identifier if it is available.

I'll add something about Address and Contact in the future....

I really want to get stuck into the search capability around patient and then look at tiniest of useful client applications, the patient contact directory, based on the Patient resource!

Check out patient records on the demo server actually some almost useful content.  You can dial up patients direct for an id range @1 to @43 on url like http://demo.oridashi.com.au:8190/patient/@N.

Published FHIR Server

Put a nicer launch page up for FHIR demo server with status and links.

Check it out at - http://oridashi.com.au/fhir/

FHIR Engine

Need a REST HTTP server up and running before the serious mapping of source clinical system data to FHIR resource definitions. My particular focus was to support a web server as a local interface to a clinical system for various downstream client usage.  The configurations I hoped to support range from:

a) Library to support FHIR server that can be integrated within desktop applications.
b) FHIR web server application that can be run in user session for other desktop applications to use.
c) FHIR service running on local network, used by desktop applications on the network.
d) FHIR web service, with some security, running as externally accessible interface to clinical system.

This is the part where HTTP based REST style services **rock**, it is just so much easier to get simple servers up and going and the result is ultra light.  I am not relying on an implementation of the WS stack where I am left wondering why my executable foot-print is so large and my processing performance slightly mysterious.

At the end of the day (and yes this has been written literally at the end of days of 'real' work that pay the bills) I am feeling this implementation is naturally clean (based on the FHIR specifications).  I understand what the wire protocol is, how it behaves and most of all I could explain the code to another developer in 15 minutes and they would be ready to go.   It means that one can concentrate on the 'clinical stuff', FHIR resources and how clinical systems can be integrated to support FHIR interactions.

Currently I have 'the' most basic of functions supported - a partial patient details record (name, gender and date of birth only) mapping to the FHIR 'Patient' resource.  This can be accessed via the normal FHIR REST HTTP interface by resource id - examples:

Formatted as XML:  http://demo.oridashi.com.au:8190/patient/@1?format=xml

Formatted as JSON: http://demo.oridashi.com.au:8190/patient/@36?format=json

Now this is JUST my FHIR web server application running on a desktop - it is NOT running behind a 'real' web server implementation.  If you are familiar with the Australia 'Best Practice' primary care clinical system you might recognise the patients as being sourced from the sample database.

I hope to keep this demo system running as I add some features - this is not a production environment so if the machine is down it is probably by accident please let me know.

Will be looking more seriously at clinical data mapping soon....

FHIR Selection

To begin the job of implementing a FHIR server wrapping an existing primary care system I will need to set some basic scope of interest.  A selection of FHIR resources that seem most appropriate to begin seems in order.  After a cursory inspection of resources list and descriptions these are my ranked candidates:

1. Patient
2. Organization
3. Problem
4. Prescription
5. Immunization
6. Observation
7. Provider
8. Order
9. DiagnosticReport
10. Document

I expect 'allergy/adverse reaction' would also be high on the list, once the arguments have died down...

Under 'Observation' I think a few basic values to include to start will be:

1. Blood Pressure
2. Tobacco Use
3. Height
4. Weight
5. Pregnancy Status

This is enough to get me going for now....

Serial Arsonist

Decided I need my own C# serialisers for FHIR, reference implementation is absolutely fine but I have some desire to build to dotNet 2.0 only... don't ask why, I just do.

So model driven code creation is the way to go.  As part of the FHIR release there are a set of technical artifacts for implementers which offer a massive leg up for those that wish to stick to completely model driven code generation.  Have a look at ecoredefinitions.xml it can be used as the basis for getting this done - I am told this is an internal source, however, it has one of the big benefits of having all of the datatypes and resources specified.

Basically, to achieve my ends, I have tackled this generation in three parts (as defined by FHIR spec)

1. Primitives : basic datatypes that map to XSD types in a nice way (and a mapping to C# types)
2. Complex/Other Types : constructed types based on primitives for common 
3. Resources : the clinical/administrative data groups 

Using the detail available to it is possible to generate serialisable classes supporting both XML and JSON representations.  The benefit here is as the resource definitions move around a bit through ballot and new additions I am trying to make the code automatically keep current.

So after some playing about I have my very rudimentary serialisable classes for dotNet 2.0 build in C#.  Of course the first resource to put something into is 'Patient' and of course for this project it has to be Mr. Burns. XML and JSON formats below.

Next.....maybe see which resources are appropriate for my GP system mapping... and how well I can map the content....

Test Patient #1 XML
<Patient xmlns="http://hl7.org/fhir">
  <text>
    <status value="generated" />
    <div xmlns="http://www.w3.org/1999/xhtml"><p>Burns, George M, 117y</p></div>
  </text>
  <active value="true" />
  <details>
    <name>
      <use value="official" />
      <family value="Burns" />
      <given value="George" />
    </name>
    <gender>
      <system value="http://hl7.org/fhir/sid/v2-0001" />
      <code value="M" />
    </gender>
    <birthDate value="1896-01-20" />
    <deceased value="false" />
  </details>
  <provider>
    <type value="Organization" />
    <url value="../organisation/@1" />
  </provider>
</Patient>

Test Patient #1 JSON

{

  "Patient": {
    "text": {
      "status": {
        "value": "generated"
      },
      "div": {
        "value": "<div><p>Burns, George M, 117y</p></div>"
      }
    },
    "active": {
      "value": true
    },
    "details": {
      "name": [
        {
          "use": {
            "value": "official"
          },
          "family": [
            {
              "value": "Burns"
            }
          ],
          "given": [
            {
              "value": "George"
            }
          ]
        }
      ],
      "gender": {
        "system": {
          "value": "http://hl7.org/fhir/sid/v2-0001"
        },
        "code": {
          "value": "M"
        }
      },
      "birthDate": {
        "value": "1896-01-20"
      },
      "deceased": {
        "value": false
      }
    },
    "provider": {
      "type": {
        "value": "Organization"
      },
      "url": {
        "value": "../organisation/@1"
      }
    }
  }
}

FHIR Starter

Task #1 An all important part of working with FHIR is coming up with fire related puns, terms and references - even though standards have no sense of humour.  After researching synonyms and related terms for a good deal longer than one ought to came to the project name 'Hiasobi' Japanese for 'playing with fire'.

To start off the real work I perused the FHIR standards page and looked at C# reference platform.   Impressions:

1. That was pretty easy to understand and get across
2. Having reference code is *extremely* helpful for implementers
3. At no point did think 'how is this related to implementing health information systems'

Now, don't get me wrong - I love my HL7 V3, I think it has developed some very important concepts and issues within health information into an approach that can work.  I have built systems with V3 for more than 8 years and it can and does work. This main issue is the 2 or so years at the start where everything you do seems to provide some new reason for a brain explosion; struggle with datatypes; difficult to implement; no tools out of the box; complicated constraint modelling and perhaps most of all the apparent drive to make health information primarily an academic pursuit. 

FHIR, however took me back to when I started HL7 V2.  It make sense straight-up, it has less moving parts so I can get across the basics in hours and the big winner (even better that V2)  - it seems to have been designed to actually be implemented by a set of well supported technologies.

More soon on core definitions and why model driven approaches rock my boat...

FHIRing Up

Time to set a challenge for myself.  FHIR v0.07 is published. Time to get into it....

So I aiming to build 'legacy wrappers' around a couple of Australian GP systems (a favourite past-time).

This time a FHIR resource based interface!

I won't be supporting POST to start; I think format and query might be enough to get my head around.

I will report as I go.

Clinical Decision Support Modelling

As part of working on clinical decision support systems over the years a constant tension remains between approaches focused on modelled or programmatic implementation of knowledge/rules.

Of course these classifications are really a sliding scale; I can produce models from programmatic statements and I can produce executable programs from a model. As a models capability to represent concepts is enhanced and made more generic - so to the complexity of the model or the possible combinations of concepts increases. This is implicitly a trade off.

The question, as always, is whether complexity is the enemy of uptake?  Standards such as GELLO allow arbitrarily complex statements to be expressed giving great ability to implement a great number of decision support system needs. However, this often leads me cold - I invariably get to the point where I ask if I am just going to program then why can't I use Javascript, it is well accepted, in use, has tools and a I have massive number of programmers available to industry.

I also find myself getting back to the basic questions of how to access a representation of a health record in a standardised fashion for writing my rules.  VMR, CDA, openEHR or FHIR?  Which concept terminology should I use?  SNOMED, what ever is local? or invent my own reference terms (à la openCDS)?

This leads me back to the position that really we are still at the point of defining service interfaces as a priority.  Definition and agreements on interactions available and payload content within a domain of use are #1.   Specific determination of capabilities of a decision support service and the ability provide appropriate input information and receive responses in useful forms (including structured and rendered) give me enough to chew on for now... still...