Last week I spoke at the CSIRO e-Health consortium. During my presentation, I said:
Open source products are the worst thing in the market.
You might find that to be a shocking claim. I certainly did the first time I heard it (which was from Seth Godin giving a keynote at EclipseCon in about 2007 – I can’t find no link now). But it’s really easy to defend the idea:
How can you sell something that’s worse than free?
A free product is the floor of the market. You can sell something better – but if your product is not better than open source, sooner or later your profitability will disappear:
Your business plan on the right if you’re not better than open source
Of course you might be able to extend your time in freefall with product lock in or regulatory capture… but sooner or later… splat!
So it follows, then, that if you publish open source, you’re not just giving something away for free, you’re changing the market. Everyone selling software has to respond – either improve or die.
Of course, it’s possible that open source is the best on the market as well as the worst. That’s already the case in some markets – very technical ones with low surface areas and big functionality volume (maths and technical tools). On the other hand, It’s not necessary that open source is or even will be the best. I don’t expect that open source will ever be the best for software that has user facing components and provides support for workflows that answer to business needs, which includes must EIS systems, notably EHR systems (though there’s already excellent open source options – e.g. openMRS yay).?
But we will see open source replacing infrastructure throughout healthcare.
Which reminds me: any organizations still selling healthcare standards material – your business plan is pretty much in the same place as the picture above. Sooner or later…
p.s. someone at the e-Health Colloquium asked me to post about this, they loved the idea so much. I couldn’t resist the clickbait title…
The Australian Digital Health Agency is working hard on replacing faxing with secure messaging. Peter MacIsaac discusses one of the ancillary challenges this causes in Pulse IT today:
The second barrier to successful cross-transfer of messages is that the messages sent by almost all health services do not comply with Australian messaging or vocabulary standards.
Likewise the major clinical system vendors are not capable of processing a standard HL7 message, if one were to be delivered to them. Senders and receivers have each interpreted the international HL7 messaging standard independently of the agreed Australian standard and associated implementation guidelines.
I don’t think this quite expresses the problem – while there definitely are problems with non-conformance, there are also areas with the Australian standards are simply not detailed enough, and a lot of the problems are in this area.
Peter also recalls that we discussed this:
A collaborative effort to achieve networking by messaging vendors some eight years ago was run in a process facilitated by IHE Australia, HL7 Australia and the MSIA
Indeed we did, and we came up with a list of issues with implementations that went beyond non-compliance with the standards. I later wrote these up for MSIA, but the MSIA never published this document and pushed for conformance to it – another lost opportunity, from my point of view. Since the document was never released openly, here it is:
Looking back at this – the document format rules around pdf, rtf, etc are problematic – that’s the set of rules that we required then – and pretty much still now – to get true clinically safe interoperability. But I don’t think many implementers in the industry can actually implement them – they depend on libraries that just don’t have that kind of control. To me, this underlines the fact that clinically safe interoperability is always going to be work in progress, since we need better standards compliance than the wider industry (so far as I know)
Lately, I’ve been describing the standards process that we’re engaged in – making a difference to people’s health through defining healthcare IT standards – as a process that has 3 legs. Kind of like this:
Well, not really. It’s actually 3 legs of a journey. The 3 legs are:
Developing the base standards
Profiling the standard for particular communities
Driving Solutions into production in the market
#1 Developing the Base Standards
The first leg is developing the base standards the define the capabilities for describing and exchanging healthcare. These base standards enable all sorts of communities to form around exchanging healthcare data.
But given the breadth of healthcare, and the variety of processes, jurisdictions and business rules – along with the fact that there’s no single authority of these things (in as much as there’s any authority at all), these are platform standards: they create platforms that are used in all sorts of different ways. They define how things can work.
They’re also limited in that they can only make hard rules that everyone in the world agrees to – which is a lot less than an particular set of rules that a single solution needs. So they don’t define particular solutions, except in the rare case that everyone in the world agrees to the solution (we actually might have a couple of those things: consumer healthcare repository, and terminology service).
#2 Profiling the Standard for Particular Communities
Once the international platform specification(s) exist, particular communities find common use cases for which they need to determine and record their business rules, and converge on a common approach for using the platform standards. These are called various things – profiles, templates, value sets, reference sets, implementation guides. But in all cases the basic steps are the same:
identify the need for a particular solution
form a smaller community around it
support the community to converge and agree on a particular approach
publish the approach and help the community test it’s validity
iterate the process
The principle is simple: a smaller communities can get more agreement amongst themselves because they have more in common (and are sometimes empowered by hard rules/regulations/laws – when they are useful)
There’s lots of organizations working in this space. Some relevant in the FHIR eco-system:
IHE (this is the classical space owned and brought into focus by IHE, from RSNA and HIMSS)
National Standards Organizations profiling FHIR / v2 / CDA
National Snomed Release centers (among other things they do)
Aside: Platform vs Usage
Note that the demarcation line between leg #1 (platform) and leg #2 (usage) is grey. I think of XDS as a platform standard, even though it’s technically profiling other standards. Thing is, that’s what FHIR does too, and it’s very definitely a platform standard. The question is far more about community and process than technology, and XDS has played out more like a platform standard (though it’s not that important which it is)
At first encounter with the standards process, many people challenge the value of the platform/usage split – why not just get it right in the first place? We’d love to – but the trade-off between community size and level of agreement is a hard external fact we can’t wish away. Given that, if you don’t create the platform/application split, the result will be a shattered standards system with myriads of incompatible standards, one for each variation of the use case and all incompatible. Which is (unfortunately) too much like what we have now. ?? It’s really nice the first time you solve a problem, but the next time you solve a related problem…. then you start to feel the pain. After the Nth time… you really want a platform standard.
#3 Driving Solutions into production in the market
Once you’ve formed a community, got your agreements, published them, and tested that it’s possible… you’re still not done. You created capability, and expectation. But at that point, nothing is actually working (except for limited demonstrations at hotels and exhibitions, typically).
Driving the solutions home – the last leg of the journey – that’s actually the hardest part of the journey. IT solution providers (vendors, usually though not exclusively) are often happy to collaborate in a community process, and demonstrate cool stuff to sell, but bringing stuff to market involves messy processes like certification, sales, deployment, contracts, and many people have to sign off on the process and someone has to fund the deployment/testing/maintenance.
The platform standard is doing well – 4th release, normative, lots of energy and adoption spreading like wild fire (sorry)
There’s plenty of projects around profiling / usage agreements from IHE and others. In particular, the Argonaut project has created a huge potential in USA with access to EHR data
But – case in point – actual argonaut end-points are not widely available, and getting access to them, even when in production, can be very difficult
HL7 has pretty much no leverage over the 3rd leg of the process. IHE has more, but not as much as everyone would like. Argonaut, in their smaller community, has more again – but still not enough. Classically, the agents that have influence/leverage over the 3rd leg are the regulators (hello CMS, ONC and the NPRM), but professional societies such as HIMSS and HISA also have influence, since their membership is much more provider based.
HL7 and the FHIR community are starting to pay much more attention to the whole 3 legs, and looking to work much more pro-actively with critical partners like IHE, HIMSS etc to see what we can do to make as much as possible real.
11:15 – 12:00: FHIR Implementations for Personal Connected Health – Hall F, Booth 9000
12:20 – 12:50: The Argonaut Project and HL7 FHIR – HL7 Booth 4849
1:00 – 2:00: Sharing SMART on FHIR Apps among VA and Other Healthcare Systems: Promise, Challenges, and Solutions – W304E
2:10 – 2:40: HL7 FHIR Update – HL7 Booth 4849
12:00 – 1:00: FHIR Interoperability: Point-of-Care Healthcare Apps in the Real World – W304A
Also, on Tuesday- Thursday:
10:15 – 5:15 (Every 15 minutes after the hour): Da Vinci Vignette – Interoperability Showcase, Booth: 9100-49 – Demonstrating Da Vinci CRD and DEQM, and Argonaut Scheduling Implementation Guides between Payers and Providers
I’m sure there’s others, and as people let me know about them, I’ll update this post. If you know of them – let me know by email (or on the social stream on chat.fhir.org)
Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide “support” for the element in some meaningful way. Because the base FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as?mustSupport=true as part of the base specification. This flag is intended for use in profiles that have a defined implementation context.
For this reason, the specification itself never labels any elements as MustSupport.
This piece of metadata is principally defined so that applications can say, in their formal descriptions of their functionality that they support a particular element. This is different to making the cardinality 1..1, so that the element must always be present.
The goto example for this element is LMP for a female patient (commonly collected on admission and particularly before xray etc for safety reasons), but obviously not applicable for many patients due to gender or age. Note, btw, that in FHIR this would be an Observation?with a LOINC code of 8665-2, and cardinality / must-support is not so simple. Never the less, it’s common to have elements that can’t be mandatory, but which systems need to support, and where it is appropriate to claim support (middle name is another good example).
It’s a little less obvious how to use must-support when writing implementation guides. Concerning this, the FHIR specification says:
When a profile [labels an element as mustSupport=true], it SHALL also make clear exactly what kind of “support” is required, as this could involve expectations around what a system must store, display, allow data capture of, include in decision logic, pass on to other data consumers, etc
In the simple case, must-support could mean that a system must store and display the element if it’s present. But profiles could go a lot further than that, particularly in the case of profiles orientated towards decision support.
The problem for profile authors is that there’s quite a lot of things to say about using elements, and must-support is a single boolean flag. Some profiles have gone to public comment and there’s been some argument about how the fine details work. So…
The first thing to remember is that must-support is a computable flag to help rendering engines highlight an element to human readers. It doesn’t have more significance than that. For example, there’s no validation hanging off it. A human has to look at the written documentation and determine what the significance is – whether writing automated test cases (e.g. TestScript), user acceptance tests, or implementing systems. So the most important focus is to get the documentation correct.
Must-Support is primarily a visual cue. I’ve never heard any discussion about implementers not having to read the documentation of all elements (though, of course, no one reads documentation if they can avoid it anyway), so not setting it doesn’t make any genuine difference.
So overall, the best thing I can say is, “chill”. (now watch the comments show a complete lack of chill…)
Dark Helmet: What the Hell am I looking at?! When does this happen in the movie?!
Colonel Sandurz: “Now.” You’re looking at “now,” sir. Everything that happens now [indicates himself and Helmet] is happening “now.” [Indicates the screen]
Dark Helmet: What happened to “then”?
Colonel Sandurz: We passed “then.”
Dark Helmet: When?
Colonel Sandurz: Just now. We’re at “now,” now.
Dark Helmet: Go back to “then”!
Colonel Sandurz: When?
Dark Helmet: Now!
Colonel Sandurz: Now?
Dark Helmet: Now!
Colonel Sandurz: I can’t.
Dark Helmet: Why?!
Colonel Sandurz: We missed it.
Dark Helmet: When?!
Colonel Sandurz: Just now.
Dark Helmet: … When will “then” be “now”?
Colonel Sandurz: Soon.
Recently, a request came up in Pharmacy to determine how best to model the request to take a medication immediately and then follow that up with a regular schedule. ?As the Pharmacy Workgroup dealt with the request, we realized that this wasn’t a Pharmacy-specific request. ?There are many times in healthcare that something needs to happen “NOW” and the means of representing “NOW” needed to be something non-Pharmacy-specific.
The obvious first place to look for representing “NOW” is the Timing datatype. ?Within that datatype, the ‘when’ code data element seems like the obvious place to represent “now”. ?Simply adding a code of “NOW” to the EventTiming value set seems like it solves the problem. ?We gain the use of the ‘offset’ data element to say “Do X 5 minutes from NOW”.
The problem of adding a code of “NOW” to the EventTiming value set is that “NOW” just doesn’t seem to be an event like the other codes in this value set. ?If you look at the set of events, every one of them is something that occurs and can eventually have a specific point in time assigned to it. ?“NOW” isn’t like that. ?If you read the excerpt at the beginning of this post, you can see the problem with NOW. ?Every point in time either was NOW, is NOW, or will be NOW. ?So what does “NOW” as an event mean?? It would be the one code that isn’t like the others.
I can’t see any other way to represent the general concept of “NOW” other than the option above, but I might be missing something. ?I’d love to hear about alternative ways of saying “Do X NOW”.
The My Health record is a noble idea but the standard they chose is from 1995, it uses PDFs, it’s not computable, it is just digitised paper,” he told News Corp Australia
Technically, the MyHR is a document repository where the repository uses a modified variant of XDS (for the ‘personally controlled’ bit) and the documents are all CDA documents. A small number of the CDA documents are simply wrappers around PDF documents (<5%) but the rest are full CDA documents with variable amounts of coded data embedded in them (some quite comprehensive indeed).
In spite of the fact that it’s a repository of CDA documents, most of the commentary in the media describes them as PDF documents, and John’s comments reflect that – based on what people told him while he was here.?
So if the repository is full of CDA documents, why all the commentary about PDF? Actually, the answer is pretty simple:?
Consumers (patients) cannot get the CDA documents; all they can get is a print out of the presented part of the CDA document – that is, in effect, PDF (and probably is literally PDF, if they print to PDF)
Aside: I’m not sure why it would be such a problem for consumers to get their own data, but this is a long standing prohibition?
Clinicians can download the CDA documents directly to their systems, and the systems are able to extract the data from the CDA documents. But mostly, this doesn’t happen (for a variety of reasons), and all the clinician gets is a presented view of the CDA document, just like if it was PDF
The purpose of the system was to collate data, but the lack of solid data and clinical agreements have made that very hard to do, and the collation views that are offered are less useful than first intended – so they’re not very high profile. More generally, the system doesn’t support integrated data based work flows – it mostly behaves like a repository of PDF documents
Finally, the public (and journalists, and politicians) have an inherent understanding of PDF (all of us read them, and many of us produce them), and use imprecise language with regard to standards . “PDF-like” quickly transits to just simply “PDF”. This even happens in the general healthcare IT community
I’ve given up trying to dispute the language – programmers and analysts working directly with the system know better, but since the system mostly functions like a repository of PDF documents, I think there’s bigger things to focus on.?
But if you like precision in your language… the MyHR is a CDA based system, not a PDF based system.
During my talk, and in regard to how to move forward in regard to Interoperability, healthcare it, the MyHR, and the continued use of faxing in Australian healthcare, I spoke about the need for us to have courage. Today, as a follow up, someone asked me:
“What kind of things should we do to have courage?”
Here’s my top 3 ways that we should act with courage in Australia.
1. Have the courage to speak the truth, and say unpopular things.
Note that this not excuse for being rude, or causing trouble. Nor is it ok to ‘speak the truth’ without first investing time to make sure it’s the truth.? But if it really is the truth, we should say so, even if it’s unpopuler. And there’s a strong view right now in Australia that people need to toe the party line. In regards to healthcare IT, that’s hurting us right now.
An obvious corollary to that is not to punish people for speaking the truth – even if you don’t agree it’s the truth. If they’ve made a good faith effort to find it, then open discussion can follow
2. Have the courage to recognise when you fail, and do something else
To many of us get ‘locked in’ to past choices – it’s a variant of the sunk cost fallacy. Particularly when it’s group activity. How does your department/company/professional society look at projects and decide they’ve turned into a death march? Is the bar to kill a project lower or higher than to create one? Do you have any evidence that you broke the sunk-cost pattern any time?
And don’t think that everything you do will succeed either. If you think it does, then either you’re not trying hard enough, or your analysis is not objective enough.?
3. Have the courage to change how you are accountable to other people
Providing healthcare is a team game, a rich complex eco-system with 1000s of specialties. The real challenge with healthcare interoperability is not getting computers to talk to each other, but getting people to change their behaviour when technology and IT means there’s better ways to do things – different kinds of accountabilities between the players in the team.?
Too often, change is too hard. Even something as simple as using faxes – a constant theme of the day yesterday. There’s no technological reason to use faxes; they’re risky, and costly, but we still are using then extensively – because of human factors. The reaction of our international guests to that discussion (and the MyHR) was revealing: astonishment at the discussion we were having.
Things aren’t going to change unless we have courage. But too many people who listened to me yesterday heard my call to courage as intended for someone else other than them. But you can’t change someone else, only yourself. You, reading this blog, ask yourself:
HL7 owns the “FHIR” ? ?trademark (along with the FHIR flame icon). While the specification itself is licensed under Creative Commons Public Domain, and can be used in anyway possible, the Trademark is not public domain; HL7 defends the trademark carefully.
What that means is that anyone can use the term “FHIR” to refer the FHIR specification – that’s called nominative use – it’s naming the thing that FHIR identifies. Note that HL7 asks that people use (R) along with the FHIR mark, at least once). But if an organisation uses the word “FHIR” to refer to something of their own, this is not nominative use, and they require written permission from HL7 to use the trademark in this fashion.
Acme, Inc is proud to announce FHIRMachinePlus,
our new interface engine
Acme, Inv invites you to Acme-On-FHIR, our new
HL7 grants written permission to organisations to use the FHIR trademark if the organisation making the application is using the mark in a way that is clearly an application of the standard, and that explains how they intend to ensure conformance/consistency with the specification. We do this to allow the community to grow and identify itself, and create findable artefacts using search engines. We’ve issued close to 100 trademark use permissions. (Btw, you can apply for written permission at http://www.fhir.org/, and since that doesn’t cost anything, you can apply even if you’re not sure that you need trademark approval).
It’s become clear, as we administer the trademark application
process, that some clarifications are needed. Firstly, two clarifications about
the existing system:
We do not, and will not, issue approvals to use
the FHIR trademark in a company name
We do not, and will not, approve the use of the
FHIR trademark in another registered trade mark. E.g. we might approve the use
of FHIRMachinePlus, but FHIRMachinePlus could never be a registered trademark
in it’s own right
Further, the current system is under revision. We are
considering changing our current system to add further conditions around the
use of the trademark. Specifically, we are considering only issuing trademark
approvals to HL7 member organisations, and only for limited periods (that due
to ongoing legal advice). Having said that, we recognise that:
There might be a mismatch between the registered
member and the organisational unit using the trademark, or it might be being
used by a consortium
Open source projects can’t be members, but we do
want to approve them
Once organisations start using the trademark
they can’t stop using them, so HL7 needs to be a faithful partner in this
None of these changes are yet made; we’ll be consulting our members for their opinion; HL7 owns the FHIR trademark for the benefit of its members, and it’s their value that we are figuring out how to maximise . This is just a heads up that the member consultation is coming.
Note :?FHIR? is the registered trademark of HL7 and is used with the permission of HL7.