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...

Oridashi talk the talk and walk the walk

Breaking blog silence - major situation change as my new enterprise Oridashi starts up.  Circumstances have lead me out of Pen Computer Systems and onto new eHealth activities, consulting and contracting to NEHTA and vendors.  Integrating with GP systems, clinical decision support and connecting to the national PCEHR the core offerings.  This move has allowed me to pay more attention to involvement with Standards Australia eHealth committees and enabled me to pursue more freely the promotion and enhancement of standards based clinical systems integration; particularly in the GP space.  At this stage I am promoting the following approaches:

1. GP integration services are offered to individual companies; this will enhance and support endeavours to access and structure health record information within their systems.  I am promoting broad and effective use of GP health records for appropriate clinical purposes.
2. Support for the implementation of systems to connect and use the national PCEHR; this includes B2B web services; CDA content based on health records from clinical information systems; and CCA (compliance) processes . I am promoting comprehensive and compliant use of the PCEHR link systems into the national repository for all systems.
3. Clinical decision support capability for knowledge resource vendors. Standards based approaches to integrating knowledge resources with clinical systems effectively - this can be supplied as delivered software components to vendors or via licensing of Oridashi clinical decision support products with ongoing support and maintenance.

If your organisation needs support in the above areas feel free to contact me directly mob: 0423 083 847 or talk to me at a HL7, Standards Australia or IHE event.

My background is highly implementation focused with a past record of delivered real world functionality.

PCEHR CCA

Compliance for CDA in progress for NEHTA Shared Health Summary and Event Summary.  I am loving it - hehe! No really, there is something gratifying with getting that XML through the validator and interpreting your world of business rules and capability to an abstract representation of all health information systems especially when you get to level 3a (structured data; I thought that was the point!). The specs themselves are pretty good to deal with but you get left with some holes every now and again where you have a case no-one has thought of, or so you may think.  When you get onto the right technical people at  NEHTA there are a lot FAQ and advice recommendations which are absolutely invaluable to getting things done and also aligning implementation across the nation.  If you have a question ask for the advice; it will end up being official advice; and part of a standard.  We are really only at the beginning of standardising implementations; there will be changes to digest and implementors better get over it; good advice helps a lot and having a body like NEHTA to own it works for me.

Beat-a-NEHTA, Better-NEHTA?

NEHTA is being beaten from many directions, and it may get worse.  Some perspective is worthwhile - Standards Australia and HL7 has always suffered from lack of volunteer resources and NEHTA has put a fairly broad scope of technical specifications, artifacts and demo implementation material together that may well have taken 10 times longer using volunteer methods.
I do wonder whether the technical aspects of the the program would have been better served by gathering experts with the historical standards development background.  I think a call to serve the program, appropriate remuneration, and a decent contract length might have enticed a number of those with the right stuff together.  I think there a probably a dozen folks that have driven standards here and abroad that given opportunity to work full time could have really accelerated outcomes.  Like any project a small switched on team can make good decisions and an expanded group can review and confirm (does sound like your average HL7 committee).
I think in general there has been some quite positive activity; I am not that impressed with the spend to achieve that activity.

CCA

Work on PCEHR projects continues. CCA for HI and SMD is on the short term plan.  HI service test cases don't make much sense for a middle-ware vendor, we don't control the behaviour of systems we connect to so having mandatory requirements wrt application operation is not really possible.  Prescriptive application functions are nice in theory but what is really mandatory?
SMD CCA is much more digestible; service/data compliance makes sense in general.  The certificate validation points are suitably wooly (NASH?) but most everything else seems fair enough.
CDA content has been parked for a while; this was the easier bit overall. We have been using it internally for a few years and Care Provision (HL7 V3) for years before that. (Level 3a NEHTA’s Common Conformance Requirements).  Can anyone do SNOMED-CT and AMT to a great extent?
CDA packaging needs some work, we have some interesting business needs for 'complete' health record extracts including clinical documents as attachments.  Not sure what is actually happening in the real world but some users seem to want attach masses of massive documents - what is a practical limit?