Opportunities Vacant in the #FHIR project

The FHIR team is continuing to grow, and has plenty of opportunities for more people to contribute.  Here are some of those opportunities:

Core FHIR spec

We’re looking for:

  • people from committees to work within committees to improve the definitions for resource, data type and profile elements and codes
  • implementers to work with the editors to develop further realistic high-quality examples that fill out resource usage
  • anyone who wants to work on proof-reading,
  • more committee members to learn how to edit specifications to give us more depth in the committees

Web Presence

We’re looking for:

  • a fhir.org web developer. If you know drupal, and you’re a member of the fhir+hl7 community, you can help with the various fhir.org services
  • more people to respond to questions on community.fhir.org

Reference Implementations

HAPI and the C# reference implementations would love to get more active contributors.

There are several roles:

  • first responder – answer questions about using them in various social media
  • tester – maintaining and extending the automated tests, and manually testing what can’t be automatically tested
  • documentation – contributing how-to and core documentation, and explaining how the RIs compare to the spec
  • committer – code contributors are also welcome

 

You can contribute to these as much as you like – a few hours here and there, up to full time.

If you’re interested in contributing in any of these roles, let me know (at grahame@hl7.org), and I’ll connect you up with the right team member.  We will be happy to provide support and direct you to necessary training material and documentation and/or set up mentor/mentee relationships to help you through the process.  If you’d like some justification to share with your manager/employer, we may be able to help there too.

If you have other ideas about how you’d like to assist, those would be welcome as well.

#FHIR and Alt-health

Unless you’ve been living under a rock, you’ve probably heard the terms ‘alt-right’ and ‘fake news’ by now. According to Wikipedia: “the alt-right (short for “alternative right”) is a loose group of people with far right ideologies who reject mainstream conservatism in the United States.” and “Fake news websites (also referred to online as hoax news) deliberately publish hoaxes, propaganda, and disinformation to drive web traffic inflamed by social media. Note: I’m well aware that Fake news websites aren’t confined to just the alt-right, but there’s a strong link between alt-right and fake news. It’s become clear, as time as progressed, that this is just another security risk in the eco-system that is the internet. Viruses, phishing, and now fake news. Something for Google and Facebook to work on – here’s some thoughts about that.

Waiting in the wings is something else I call ‘Alt-Health’ – the spread of bad healthcare advice running like wildfire through social media. One particular aspect of if – the anti-vaxxer campaign – that’s getting air time in the mainstream press, but it’s much broader problem than just that. Bad medical advice on the internet is nothing new – e.g. Google have a team devoted to working on the quality of web pages returned for medical related searches. But the spread of bad advice on social media is outside that. And it’s not always wrong advice, actually. Sometimes, it’s extremely good advice for one patient, but wrong for another patient. But it’s handed on as gospel – ‘this worked for me, so ignore your doctor and do what’s proven to work’… if only life were so simple. Looking forward, I expect that this is going to turn into an epidemic, as people turn away from complexity and cost, seeking simple solutions. What they’ll get is outright wrong or wrong in context, and it’s going to kill people. On the other hand, we know that while a lot of the advice is bad, it can also be very good as well. In some circumstances, better than the clinical advice a patient gets, particularly for rare diseases.

People are going to need trusted healthcare advisers to sort of good advice from bad advice. Unfortunately, there’s a challenge here: some advice will be 100% stupid and wrong (you can cure cancer by eating the right vitamins) while other advice will be 100% right and true (you should stay on the treatment advised by your clinical team, or talk to them if it’s not working out), but a lot of advice is going to fit into the category ‘or maybe true, depending on circumstances’.

That’s where FHIR enters the picture: the FHIR standard has the coverage of this space:

  • Patient’s can get their clinical data in the FHIR format – their past records, their diagnosis with supporting evidence, and their care plan
  • They can share their with their trusted adviser
  • As well, decision support services, criteria, quality measures, clinical evidence, provenance chains – all these can be represented in FHIR (including from the micro-patient communities that have the expertise)
  • We’re working with the biopharma industry to formalise trial data reporting too

Though there are many other standards at play here, FHIR is the one that links all this space together, and naturally fits into the web/internet eco-system.

So I believe that one of our key activities in the FHIR community over the next few years will be ensuring that the standards are in place to address the challenge that alt-health brings – that is, to enable clinical decision support to rank the reliability of random advice on the internet.

 

Verhoeff Algorithm in Delphi

I needed an implementation of the Verhoeff check digit algorithm in Delphi, and couldn’t find one. So reproduced here for ease of use by anyone else who needs it:

const
 verhoeff_d : array[0..9,0..9] of integer = (
 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9),
 (1, 2, 3, 4, 0, 6, 7, 8, 9, 5),
 (2, 3, 4, 0, 1, 7, 8, 9, 5, 6),
 (3, 4, 0, 1, 2, 8, 9, 5, 6, 7),
 (4, 0, 1, 2, 3, 9, 5, 6, 7, 8),
 (5, 9, 8, 7, 6, 0, 4, 3, 2, 1),
 (6, 5, 9, 8, 7, 1, 0, 4, 3, 2),
 (7, 6, 5, 9, 8, 2, 1, 0, 4, 3),
 (8, 7, 6, 5, 9, 3, 2, 1, 0, 4),
 (9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
 );
// The permutation table
 verhoeff_p : array[0..7,0..9] of integer = (
 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9),
 (1, 5, 7, 6, 2, 8, 3, 0, 9, 4),
 (5, 8, 0, 3, 7, 9, 6, 1, 4, 2),
 (8, 9, 1, 6, 0, 4, 3, 5, 2, 7),
 (9, 4, 5, 3, 1, 2, 6, 8, 7, 0),
 (4, 2, 8, 6, 5, 7, 3, 9, 0, 1),
 (2, 7, 9, 3, 8, 0, 6, 4, 1, 5),
 (7, 0, 4, 6, 9, 1, 3, 2, 5, 8)
 );
 //The inverse table
 verhoeff_inv : array [0..9] of char = ('0', '4', '3', '2', '1', '5', '6', '7', '8', '9');

//For a given number generates a Verhoeff digit
function genCheckDigit(s : String): char;
var
 i, c, len : integer;
begin
 c := 0;
 s := s + '0';
 len := length(s);

 for i := len downto 1 do
   c := verhoeff_d[c][verhoeff_p[((len-i) mod 8)][ord(s[i]) - ord('0')]];

 result := verhoeff_inv[c];
end;

////Validates that an entered number is Verhoeff compliant.
////The check digit must be the last one.
procedure validateCheckDigit(s : String);
var
 i, c, len : integer;
begin
 c := 0;
 len := length(s);

 for i := len downto 1 do
   c := verhoeff_d[c][verhoeff_p[((len-i) mod 8)][ord(s[i]) - ord('0')]];

 if c <> 0 then
 raise Exception.Create('Check digit error: "'+s+'" is not valid by Verhoeff algorithm');
end;

 

Support for Testing in the #FHIR Specification

On the last day of the baltimore meeting, a small group of us met to talk about the future of testing in the FHIR specification. In particular, the participants included both Aegis and Mitre, who develop Touchstone and Crucible respectively. Out small group made 3 decisions:

  1. We will work towards the adoption of a formal testing framework for FHIR interfaces
  2. We will simplify the existing TestScript resource
  3. We will draft and propose a TestReport resource

Taking these backwards:

The TestReport will contain a summary of the outcomes a test run – which tests were run, whether they passed, and references to a further information (logs, etc). It’s for helping to maintain current registries of implementations and outcomes. I’ll blog about this further once there’s a draft to look at.

I’ll comment on #2 in time, when we have a draft for people to consider.

For #1, a testing framework, we have several motivations for this:

  • It’s well known that a problem with testing processes like IHE is that under the right care (e.g. configuration) and with some judicious off-road modifications, systems can pass their IHE testing – but that often doesn’t equate to conformant implementations in practice
  • Many systems undergo stringent testing in-house in continuous builds, but real world integrations are extremely hard to test
  • As a consequence, applications are often poorly tested prior to upgrade
  • Every real clinical system I’ve worked with has had test patients so that staff can check how the system works. In Australia, custom is that the patients are called Donald Duck, Mickey Mouse, etc. Staff just have to magically ‘know’ that these are test patients, and they pollute stats etc a little
  • One near exception is the Australian MyHR, for which there was no test system, and no possibility of test patients. In practice, people trying to use it had to use their own personal records as test patients (many told me that they did this, and bits of those records drifted into the media)

We’d like to normalise testing – to make clear expectations about how production systems could be tested, and to start encouraging production systems to actually provide such support. Two key corollaries of this – administrators can download the official tests (e.g. IHE, or others) and run them against their system with robots playing the part of the the other system. And also, the testing framework starts to acquire a clinical safety role – adminstrators can add new tests to their own automated tests for the application (e.g. prior to upgrade or configuration change) and assure themselves that known system requirements with regard to system safety are assured. Note that this is something you can only do in the context of a fully configured and linked system of systems – which is why support for testing in production systems is so important in this regard.

Anywhere, he’s a set of ideas to get people thinking about how this all might work:

  • Resources on the FHIR API are either ‘Production’ or ‘Test’. There will be a ‘test’ tag that labels all the test resources accordingly. No tag = not testing
  • Resources labelled ‘test’ are allowed to refer to production records (e.g. for configuration) , but never the other way around
  • Requests may be labelled ‘test only’ or ‘test and production’. Default is production.
  • Clients that have either ‘test’ or ‘test-only’ on requests SHALL indicate clearly to users that this is the case
  • Operations on test resources that use production resources internally on the server (e.g. $expand) are allowed in ‘test only mode’
  • Conformance resource : add a ‘testCompartment’ : boolean flag where true means that the system offers the same services as in production, but in test mode
  • If a system supports a test compartment, it also supports a $clear operation on the test compartment – it clears all the records associated with the test compartment (including audit records), so to reset for an automated test run
  • Testable Systems can be the target of a test engine that executes a set of tests, and which can produce a test report for archival / comparison purposes
  • System administrators can write tests against their system – e.g. clinical safety focused using TestScripts – and these test scripts can cross multiple systems
  • Systems are allowed to make their own arrangements regarding multiple test compartents (e.g. per authorised user)

Anyone with any engineering experience will immediately recognise that implementing this set of requirements is a major design undertaking. It’s not going to happen quickly in existing EHRs, unless s conceptually similar system already exists – but I’ve never seen one.

But if we regularise the interface, and the test servers implement it (not too hard in my server) – then we might encourage movement in this direction gradually, and that would make it cheaper to deliver truly reliable systems….

#FHIR – Adding Identifier to Reference

One of the more controversial sessions at the Baltimore meeting was where we discussed task 10659:  Reference should support logical references

This is a difficult subject because it relates to handling and exchanging information where a formal URL based view of the world is incomplete. In effect, that means, from a purist point of view, the world is already broken. This makes effective resolution difficult; at best, the resolution is also going to be broken – but is it broken in the least unuseful way? – that’s a bad place to try and get consensus from.

Further, in the FHIR framework, the Reference data type is clearly FMM level 5 – it’s been hammered everywhere from the beginning and is production in all sorts of places. And we’ve said that we won’t make breaking changes to FMM level 5 artefacts without consultation with the users. What’s not clear, though, is whether any of the changes that were proposed in the extensive discussion leading up to the quarter devoted to the task (see, for example, here and here) were actually breaking changes.

The outcome of the meeting was that we would add an Identifier to the Reference data type. Given the background, there was fairly strong consensus for the change, but it wasn’t complete. As a consequence, we said that we would define the change, let everyone look at it for a month, and see if any argument comes up that we had not considered.

So I’ve made the changes: see the Reference data type in the current build. Implementers are encouraged to evaluate the impact of this addition in their implementations, and share their findings on the FHIR email list.

Note: since this is not strictly a breaking change, this is not strictly consulting the implementers before making a breaking change 😉

#FHIR DevDays event is coming up

I’m finally on the way home from the HL7 Baltimore meeting. That means that the next main event for the FHIR community is the DevDays meeting in Amsterdam, organised by Furore. This just gets better every year.

The 2016 edition of the International HL7 FHIR Developer Days (16-18 November in Amsterdam) includes a tracks on many subjects, and – as is the practice of the FHIR community – features collaborations with other communities. In particular, this year, we’ll be sharing tracks with the openEHR and The Continua Alliance communities. The speaker line-up is a hall of fame of FHIR and I’m proud to be part of it. Participants of DevDays are free to follow any of the tutorials and hands-on sessions.

If you are interested in “my” track or in FHIR in general, don’t forget to sign up before September 30th, which is the Early Bird deadline and saves you 300 Euro.

I really enjoy the DevDays style, and it’s one of the best meetings I go to. It’s also the best way to engage with the FHIR community and work if you’re in Europe. I’ll see you all there!

 

#FHIR: Comments in JSON

We use XML comments extensively in FHIR for the examples in the specification:

  <Patient xmlns="http://hl7.org/fhir">
    <!-- this example patient shows how to use ... -->
  </Patient>

Generally, comments are only useful in examples for the specification and implementation guides.

Unlike XML, JSON doesn’t have a comments syntax. Standing advice is to put the comment in some property, so that’s what we did:

  {
    "resourceType" : "Patient",
    "fhir_comments" : "this example patient shows how to use ..."
  }

But there’s problems with that approach – you’re parser has to parse them, and many people have trouble with the idea that you can truly ignore them. Then, if you’re using JSON schema, you have to allow for them. Also, if you’re round-tripping with XML, you lose the exact position of the comment. Finally, must human readers miss the comment anyway, since it’s in a property – and the human readers are the only point of having comments. (So many people use custom variations to include comments, but that’s not an option we have. The JSON community is discussing that, but it seems unlikely it will change, or if it changes, be widely adopted).

The cumulative effect of all this is that, as a consequence of a ballot comment (disclosure: from me) the HL7 ITS committee proposes to remove support for comments from the FHIR JSON format. Specifically, we propose to remove this paragraph:

There is no inherent support in JSON for a comment syntax. As a convention, content that would be comments in an XML representation is represented in a property with the name fhir_comments, which is an array of strings, which can appear on any JSON object. This is heavily used in example instances, e.g. in this specification, but not usually used in production systems (and production systems may choose to reject resources with comments in them)

We don’t know of anyone using this in practice, and for practical reasons, I removed comments from the actual JSON examples in the current version earlier this year, and we’ve had no comments about that. Never-the-less, the JSON format is labelled FMM 5 (see the specification definition), so we need to consult with the implementation community about this.

So we are calling for comment from implementers about this change. If you wish to comment on this change, please send an email to the FHIR email list before Octover 11th 2016. If you comment against this change, make sure you identify the production implementation that would be affected by the change, and how it would be affected.