I have working on HL7 standard for many years and now have started to learn FHIR. What would be your recommendation?
In general, there are 4 ways to learn abut FHIR:
I have working on HL7 standard for many years and now have started to learn FHIR. What would be your recommendation?
In general, there are 4 ways to learn abut FHIR:
This is post #3 in my series about why to participate in the FHIR standards process.
A few weeks ago, I attended the AIIA awards night at the kind invitation of the eHealth team from CSIRO. One of the speakers was the Victorian Minister for Small Business, the Hon Philip Dalidakis. The presentation was the day after the sad passing away of another Victorian minister, Fiona Richardson, and in her memory, he made an inspired plea for us all to actively consider whether there’s anything that we can or should do to improve the gender imbalance that’s typical in IT.
HL7 – and the FHIR community – does have the gender imbalance that’s characteristic of IT communities – though it’s also a health community, and so the gender divide is not as stark as it is in some communities. But it’s not anywhere close to 50:50, and his words made me wonder whether we/I are in a position to do anything more about that. After the presentation, I spoke to Minister Dalidakis about what levers we might have in an open standards community to encourage more balanced participation – they’re different to those you can/should use in a commercial setting. He graciously gave me several pieces of advice, and since then I’ve been discussing this with the FHIR team, and particularly with our female leaders in the community.
FHIR and HL7 are great communities to be involved with, and that’s particularly true if you’re a woman – that’s what our female leaders tell me.
They say this is because:
And FHIR is a great place to contribute. Paula Braun says:
Many of the important indicators about our health…e.g., blood pressure, abnormal lab results, etc…are invisible to us. Without access to this data, we and the professionals we entrust to take care of us, are operating in the dark. The older, outdated ways of accessing and exchanging health information have an “I know better than you” feel to them. It was the equivalent of somebody saying, “Hey there girl, don’t worry your pretty little head about how this all works. It’s much too complicated for you.” FHIR is different. FHIR is a community where motivated people self-select to un-break healthcare…at least the IT part of healthcare. I don’t consider myself a “techie” but I choose to participate in the FHIR community because of the possibilities that FHIR enables, the professionalism that is maintained, and, most importantly, because its fun to be part of a movement that is transforming the dominant assumptions and expectations about healthcare
Michelle Miller (who is rightfully one of the Health Data Management’s 2016 Most Powerful Women in Health Care IT) says:
I participate in the FHIR community because:
- Even with my bright pink “First-Time Attendee” ribbon, I quickly learned that my input was valued.
- HL7 FHIR has a focus on those who adopt and implement the standard specification, such that implementer involvement and input is very much respected and encouraged.
- After getting energized by the fantastic collaboration that occurred during the HL7 work group meetings, I started attending weekly work group conference calls to continue the discussion
- I feel strongly that all changes, big and small, help make the FHIR specification that much better for the next implementer or developer to adopt. Adoption is what makes a specification a standard because without adoption, we haven’t really achieved interoperability
- I have been so impressed with the knowledge, collaboration and overall friendliness of the HL7 FHIR community. The discussion is always thoughtful and respectful, such that I have high confidence in FHIR’s ability to maximize interoperability.
In sum, it is energizing for me to collaborate with such knowledgeable experts on a subject (healthcare) that is so meaningful and impactful (bigger than just me, my job, or even my country). Despite the diversity in our perspectives (country, vendor, government, technical vs clinical etc.), the FHIR community is genuinely interested in reaching the best conclusion because adoption is what makes a specification a standard and achieves interoperability
Michelle has a full write up about her involvement on the Cerner Blog.
So the FHIR community is a great place for women who want to make a difference to contribute. If you’re thinking about it – we’d love to have you involved; please get in contact with me, or one of:
(though there’s many other valued contributers as well).
Still, there’s plenty we can do to improve:
Note that all these are really about maximizing our human capital. So, we have plenty of potential, but we aren’t really capitalizing on it. Increasingly, we are investing in human capital as our community grows, so watch this space.
Btw, this image from the Madrid meeting shows that we can do better on balance (though, in fact, we are on the whole more balanced than this particular photo):
Contributers recognized for contributions way beyond expectations to getting FHIR R3 published – featuring both Melva and Michelle
p.s. A note about the FHIR and HL7 communities: these are tightly related communities with a good % overlap, but they are also different in nature, processes, and composition, so we had to consider them both.
Unofficial FHIR project historian Rene Sponk has pointed out that it’s exactly 5 years to the day since I posted the very first draft of what became FHIR:
Five years, on August 18th 2011 to be precise, Grahame Grieve published the initial version of FHIR (known as RFH at the time) on his website. The date of the initial version was August 11th – which is the reason for this post today. Congratulations to all involved for helping to create a success – FHIR has gained a lot of interest over the past few years, and a normative version will be published in the near future.
Wow. 5 years! Who would have thought that we’d end up where we are? I really didn’t expect much at all when I first posted RfH back then:
What now? I’m interested in commentary on the proposal. If there’s enough interest, I’ll setup a wiki. Please read RFH, and think about whether it’s a good idea or not
Well, there was enough interest, that’s for sure.
And it’s rather a coincidence, then, that on the 5th anniversary of the first posting, I’ve just posted the ballot version for the STU 3 ballot. This version is the culmination of a lot of work. A lot of work by a lot of people. Lloyd Mckenzie and I have been maintaining a list of contributers, but so many people have contributed the specification process now that I don’t know if we’re going to be keep even a semblance of meaningfulness for that page. I’ll post a link to that version soon, with some more information about it
p.s. Alert readers will note that the blog post announcing RfH was dated Aug 18th – but it was first posted August 11th.
One topic that comes up fairly often when I talk procurers and users of interoperability is ‘clinical safety’. Everyone knows why it’s important, but it’s much harder to pin down what it is, and how to measure it, or how to ‘be safe’. With this in mind, the FHIR specification includes an implementer safety checklist. All developers implementing FHIR should run through the content of this safety checklist before and after the implementation process. But the lack of feedback I get about it suggests to me that not many people read it.
With this in mind, I’ll be asking participants in this weekend’s connectathon in Orlando to fill it out. I’m sure we’ll get comments from that. Here’s the safety checklist, with my comments, but first:
Almost all interoperability developments occur in a limited context with one to a few trading partners, and relatively well controlled requirements. In this context, safety consists of testing the known functionality, but all too often, ignoring all the other things that might happen. However experience shows that over time, new participants and new requirements will creep into the ecosystem and safety features that appeared unnecessary in a well controlled system turn out to be necessary after all. These safety checks below are mostly chores, and are easily ignored, but a warning: you ignore them at your peril (actually, it’s worse than that- you ignore them at other people’s peril).
Production exchange of patient or other sensitive data will always use some form of encryption on the wire.
This is a fairly obvious thing to say in principle, but it’s extremely common to find insecure exchange of healthcare data in practice. FHIR does not mandate that all exchange is encrypted, though many implementers have commented that it should. There are some valid use cases not to use encryption, such as terminology distribution etc. Implementers should check that their systems are secure.
For each resource that my system handles, I’ve reviewed the Modifier elements.
In resource definitions, a number of elements are marked as modifying elements. Implementers are not required to support these elements in any meaningful fashion. Instead, implementers are required to ensure that their systems do not inappropriately ignore any of the possible values of the modifier elements. This may be achieved by:
Note that applications that store and echo or forward resources are not ‘processing the resources’. Processing the resources means extracting data from them for display, conversion to some other format, or some form of automated processing.
My system checks for modifierExtension elements.
Modifier Extensions are only seen rarely, but when they exist, they mean that an implementer has extended an element with something that changes the meaning of the element, and it’s not safe to ignore the extension. For safety purposes, implementers should routinely add some kind of code instruction like this:
Assert(object.hasNoModifiers, “Object at path %p has Unknown modifier extensions”)
This should be done for each object processed. Of course, the exact manifestation of this instruction will vary depending on the language. Performing these checks is a chore, so it’s frequently not done, but it should be done for safety purposes. Note that one cheap way to achieve this is to write a statement in the documentation of the application: “Do not send this application any modifier extensions”. Like all cheap ways, this is likely to not be as effective as actually automating the check.
My system supports elements labelled as “must-support” in the profiles that apply to my system.
Implementation Guides are able to mark particular elements as ‘must-support’. This means that although the element is optional, an application must be able to populate or read the element correctly. What precisely it means to do this correctly varies widely, so Implementation Guides must indicate exactly what they mean when marking an element as ‘must-support’, and applications that claim to conform need to do whatever is prescribed.
For each resource that my system handles, my system handles the full Life cycle (status codes, record currency issues, and erroneous entry status). Many resources have a life cycle tied to some business process. Applications are not required to implement the full business life cycle – they should implement what is needed. But systems need to fail explicitly if the life cycle they expect does not match the content of the resources they are receiving
A common and important area where applications fail to interoperate correctly is when records are created in error, or linked to the wrong context, and then must be retracted. For instance, when a diagnostic report is sent to an EHR linked to the wrong patient. There are a variety of ways to handle this, with different implications for the record keeping outcomes. Failure to get this right is a well-known area of clinical safety failure.
The FHIR specification makes some rules around how erroneous entry of resources is indicated. Applications should ensure that they handle these correctly.
My system can render narratives properly (where they are used).
The general theory of text vs data is discussed here and here. Resources can contain text, data or both. Systems are not obliged to be able to display the narrative; they can always choose to process the data. But in many cases, it’s a good idea to offer the user a choice to see the original narrative of the resource (or resources, in many cases), particularly for clinical resources. This might be described as ‘see original document’ in a user relevant language.
The FHIR specification makes no explicit requirements in this regard, since the correct behaviour is so variable. Implementers should judge for themselves what is appropriate in this regard.
My system has documented how distributed resource identification works in its relevant contexts of use, and where (and why) contained resources are used.
Many of the clinical safety issues that arise in practice arise from misalignment between systems around how identification and identifiers work. In the FHIR context, this risk is particularly acute given how easy it is to develop interfaces and connect systems together. Any applications that assign identifiers or create resources with an explicit identity should document their assumptions and processes around this. This is particularly important where there is the prospect of more than two trading partners.
The same applies to contained resources: a system should refrain from using contained resources as much as possible, and where it necessary, document the usage.
My system manages lists of current resources correctly.
One important use of the List resource is for tracking ‘current’ lists (e.g. Current problem list). Current lists present a challenge for the FHIR API, because there’s no inherent property of the list that marks it as ‘current’: there may be many ‘medication lists’ in an application, but only a few(or one) of them are the ‘current’ list. What makes a list current is it’s context, how it used, not an inherent property of the list. The FHIR API defines an operation that can be used to get a current list for a patient:
The FHIR specification defines several list tokens for use with this operation but there’s a long way to go before these concepts are well understood and exchangeable. If the system has current lists, it must be clear how to get the correct current list from the system and how to tell the lists that are not.
My system makes the right Provenance statements and AuditEvent logs, and uses the right security labels where appropriate.
Provenance and AuditTrail are two important and related resources that play key roles in tracking data integrity. Provenance is a statement made by the initiator of an update to the data providing details about the data change action and AuditTrail is a statement made by the data custodian about a change made to the data. On a RESTful API, the provenance statement is made by the client, and the AuditTrail is created by the Server. In other contexts, the relationships may not be so simple
My system checks that the right Patient consent has been granted (where applicable).
Patient consent requirements vary around the world. FHIR includes the ability to track and exchange patient consent explicitly, which is a relatively new integration capability. Various jurisdictions are still feeling out how to exchange consent to meet legislative and cultural requirements.
When other systems return http errors from the RESTful API and Operations (perhaps using Operation Outcome), my system checks for them and handles them appropriately.
Ignoring errors, or not handling them properly, is a common operational problem when integrating systems. FHIR implementers should audit their system explicitly to be sure that the http status code is always checked, and errors in OperationOutcomes are handled correctly
My system publishes a conformance statement with StructureDefinitions, ValueSets, and OperationDefinitions, etc., so other implementers know how the system functions.
While servers have no choice but to publish a conformance statement, the degree of detail is up to the implementer. The more detail published, the easier it will be for systems to integrate. Clients should also publish conformance statements too, but there is much less focus on this – but the computable definition of system functionality will be just as important.
My system produces valid resources.
It is common to encounter production systems that generate invalid v2 messages or CDA documents. All sorts of invalid content can be encountered, including invalid syntax due to not escaping properly, wrong codes, and disagreement between narrative and data.
In the FHIR ecosystem, some public servers scrupulously validate all resources, while others do not. It’s common to hear implementers announce at connectathon that their implementation is complete, because it works against a non-validating server, and not worry about the fact it doesn’t work against the validating servers.
Use the validation services to check that your resources really are valid, and make sure that you use a DOM (document object model) or are very careful to escape all your strings
Check for implicitRules.
All resources can carry an implicitRules pointer. While this is discouraged, there are cases where it is needed. If a resource has an implicitRules reference, you must refuse to process it unless you know the reference. Remember to check for this.
An important principle in interoperability is Postel’s Robustness Principle:
Be conservative in what you send, be liberal in what you accept
There’s been quite a bit of discussion recently in various implementation forums about robustness of FHIR interfaces, and I think there’s a few things to say about how to develop robust FHIR principles.
Firstly, the FHIR core team endorses Postel’s principle – the pathway to robust interoperability is to be careful to be conformant in what you send, and to be as accepting as possible in what you receive. However, in practice, it’s not necessarily easy to see how to implement like that.
There’s also some circumstances where this isn’t what you should do. As an example, when I started writing my reference server, I followed Postel’s law, and accepted whatever I could accept. However this fostered non-conformant implementations, so on the behest of the community, I’ve been gradually tightening up the rigor with which my server enforces correctness on the clients. For example, my server validates all submitted resources using the formal FHIR validator. Somewhat unfortunately, the main effect that has had is that implementers use one of the other servers, since their client works against that server. This’ll get worse when I tighten up on validating content type codes in the lead in to the Orlando Connectathon. Generally, if an implementation is used as a reference implementation, it should insist that trading partners get it right, or else all implementations will be forced to be as generous as the reference implementation.
But let’s assume you wanted to follow Postel’s law. What would that mean in practice, using a FHIR RESTful interface?
If you’re creating a resource, then you can start by ensuring that your XML or JSON is well formed. It’s pretty much impossible for a receiver to process improperly formed XML or JSON (or it’s at least very expensive), but experience shows that many implementers can’t even do that (or here), and I’ve seen this a lot. So for a start, never use string handling routines to build your resources – eventually, you’ll produce something invalid. Always always use a DOM or a writer API.
In fact, in general, if you are writing a resource, you should ensure that it passes the validator (methods for validation), including checking against the applicable profiles (whether they are explicit – stated in Resource.meta.profile – or implicit – from the conformance statement or other contextual clues).
If you’re reading a resource, then:
However, there’s not that much you can be graceful about with the content; generally, if you have to use it, it has to be right.
Using the RESTful API
In practice, when using the API, clients should ensure that they:
Note: the full multi-dimensional grid of request/response mime types, and the _format header is long and complex, so we’ve not specified the entire thing. As a consequence, outside of these recommendations above, there’s dangerous waters to be encountered.
One area that’s proven controversial in practice is how to handle HTTP parameters. With regard to search, the FHIR specification is quite specific: a server SHALL ignore HTTP parameter that it does not understand. This is because there may be reasons that a client has to add a parameter to the request because of requirements imposed by HTTP agents that intercept the request before it hit’s the FHIR server (this may be clients, proxies, or filters or security agents running on the server itself). In the search API, a server specifically tells a client which parameters it processed in the search results (Bundle.links, where rel = ‘self’), but this doesn’t happen in other GET requests (read, vread, conformance).
For robustness, then, a client should:
A server should:
The things above really deal with syntactical variance. Postel’s Principle is relatively easy to apply in this way. It’s much harder to apply when the underlying business process vary. Typical examples include:
To grapple with these issues, I’m going to work with the last example; it’s the easiest to understand and apply, though the basic principles apply to the others as well. In this case, we have 2 applications exchanging data between them, and they support different sets of codes. There’s a few different possibilities:
The way the CodeableConcept data type works is intimately linked to practical resolutions to these common cases. In order to support these cases, it has a text representation, and 0 or more Codings:
In HL7’s experience, Postel’s Principle, as applied to the exchange of coded information, says that
Note: there’s a wide variety of workflows that lead to the choice of a concept, and the process for selecting the text and the multiple codings varies accordingly. Since the subtle details of the process are not represented, the most important criteria for the correct choice of text is ‘does a receiver needs to know how the data was collected to understand the text’
Note: this implies that there’s a process difference between ‘adding another code for the same concept’ and ‘changing the concept’ and this change should be reflected in the information level APIs and surfaced in the workflow explicitly. But if there’s no difference…
Many, if not most, systems, do not follow this advice, and these often have workflow consequences. Note, though, that we’re not saying that this is the only way to manage this; more specific workflows are appropriate where more specific trading partnership details can be agreed. But the rules above are a great place to start from, and to use in the general case.
Beyond this general advice, specific advice can be provided for particular contexts. Here, for instance, is a set of recommendations for RxNorm:
There’s a whole art form around version management of terminologies. I’ll take that up in a later post.
Dealing with People
One last comment about Postel’s principle: Interoperability is all about the people, and the same principle applies. If you want to interoperate, you need to get on with people, and that means that you need to use Postel’s principle:
Be generous with what other people say, be disciplined with what you say
A community of people who want to interoperate with others – I’d like to be part of that. But no, I already am! The FHIR community has been very good at this over the last few years.
p.s. this post dealt with the RESTful interface, but the basic principles apply in other contexts of use as well.
There’s an enquiry into the pcEHR at the moment. As one of the small cogs in the large pcEHR wheel, I’ve been trying to figure out whether I have an opinion, and if I do, whether I should express it. However an intersection of communications with many people both in regard to the PCEHR, and FHIR, and other things, have all convinced me that I do have an opinion, and that it’s worth offering here.
There’s a lot of choices to be made when trying to create something like the pcEHR. In many cases, people had to pick one approach out of a set of equivocal choices, and quite often, the choice was driven by pragmatic and political considerations, and is wrong from different points of view, particularly with regard to long-term outcomes. That’s a tough call – you have to survive the short-term challenges in order to even have long term questions. On the other hand, if the short term decisions are bad enough, there’s no point existing into the long term. And the beauty of this, of course, is that you only find out how you went in the long term. The historians are the ones who decide.
So now that there’s an enquiry, we all get to second guess all these decisions, and make new ones. They’ll be different… but better? That, we’ll have to wait and see. Better is easier cause you have hindsight, and harder because you have existing structure/investment to deal with.
But it seems to me that there’s two underlying issues that need to be confronted, and that if we don’t, we’ll just be moving deck chairs around on the Titanic.
Social/Legal Problems around sharing information
It always seemed to me that in the abstract, the pcEHR make perfect sense: sharing the patient’s information via the person most invested in having the information shared: the patient. The patient is the sick one, and if they choose to hide information, one presumes that this is the same information they wouldn’t volunteer to their treating clinician anyway, so what difference would it make?
Well, the difference between theory and practice is bigger in practice than in theory.
And the thing I’ve heard most often in the last couple of weeks with regard to the pcEHR is “it’s neither fish nor fowl” – is it a clinical record, or a patient record? I’m sure that the enquiry will be inundated with comments about this, but there’s a deeper underlying question here: what’s the clinician’s liability in regards to sharing information? (both outgoing and incoming). If a clinician does not discover a condition because it’s not listed in the pcEHR, and they didn’t ask the patient, would it (ever) be an acceptable defense that you would expect it to be? Is that something that would come about naturally by osmosis (or something), or is there active cultural and legal changes needed here?
I’m not a clinician, but I rather think it’s the second. But there’s probably a mexican stand-off here – you couldn’t find out whether this would be reasonable till the (x)EHR is a Big Thing, and it won’t ever have any chance of being a Big Thing until this is resolved.
So the enquiry can recommend whatever it wants, but this underlying question isn’t in it’s scope, so far as I can see – and so it probably won’t make much difference?
Now I raise this – in spite of the fact I’m not a clinician – because it actually frames my second issue, and that’s something I do know about. The way it frames the second issue is that I don’t know whether the pcEHR is just a path for sharing information with the patient, or whether it’s actually intended to grow into the real patient care system that everything else is an extension of (the pcEHR documentation is a dollar each way on this issue, so I’m never sure). If the answer is the first – it’s a one way pipe to the patient, then my second issue is irrelevant. But I’ll still raise it anyway because lots of people are behaving as if the goal is a real healthcare provision system.
Lack of Technical Agreement
The underlying pcEHR specifications for clinical agreement are the CDA document specification stack, consisting of the “Core Information Components”, the “Structured Document Templates” (aka Structured Content Specifications), and the CDA Implementation Guides. At interest here is the Core Information Components, which say:
The purpose of the [X] Information Requirements is to define the information requirements for a nationally agreed exchange of information between healthcare providers in Australia, independent of exchange or presentation formats.
Then they say:
Note that some of the data elements included in this specification are required for ALL [X], whereas others need only be completed where appropriate. That is, a conformant [X] implementation must be capable of collecting and transferring/receiving all Information Requirement elements.
What this means is that these documents are a minimum required functional set – all parties redesign their systems to do things this way, and we’ll all be able to exchange data seamlessly.
There’s no discussion in these documents about the idea of systems doing extra pieces of data not discussed by the core information components, but the underlying approach really only works if there aren’t any. The problem is that this is “core” components – and that’s very much a reflection of the process – these are things everyone agreed to (where “everyone” turns out to mean, the people who were talking to NEHTA back then, which is far short of everyone who will implement). That leaves a lot of things out of scope.
So there’s problems here in two directions – what if systems don’t support the core components? What if they have other things?
Now the pcEHR was built on top of these specifications, and some parts of the pcEHR design expected that things would follow the core components – particularly, any part that implied data aggregation, analysis, or extraction. As long as the pcEHR is documents inbound, document navigation, and document view, the conceptual gaps the core information components leave don’t matter.
But as soon as you start wanting to do composite views, summaries, etc, you need to be sure about the data. And deviations from the Core Information Components make that impossible. And, in practice, many of the contributing systems deviate from the core information component specifications by not supporting required fields, adding extra fields, or having slightly different value sets for coded values etc. There was this expectation that all the systems would be “adjusted” to conform to these core information components. And some were, though sometimes in some strictly notional sense that the users will never use. But many systems never even tried, and it just wasn’t going to be practical to make them.
It probably sounds like I think the core information components are flawed, but I don’t really think they are – I think the issues I have listed should be understood as that we have found the limits of agreement within Australia in these regards. Given a much longer development time, a lot more money, and a lot better engagement, we could have added a few more fields, but I don’t think it would’ve made much more difference. The problem is the existing systems – they are different. And may be they could be rewritten, but that would cost a vast amount of money, and what would happen to the legacy data?
So any useful clinical leverage from the pcEHR in terms of using the data is pretty much a non-starter right now. Only the NPDR, where the prescribe and dispense documents are locked right down – only there do we have useful data analysis happening (and so far, we have only a few providers set up to push data to the NPDR. I wonder how others will go – but prescription is a fairly proscribed area, so this might be ok).
I don’t see how the enquiry can make much difference in this area either – this is a generational problem. I guess there can be lots of moving the deck-chairs around, and blaming the symptoms. That’s how these large projects usually go….
On November 12 in Sydney, I’ll be leading a “Clinical Safety for Healthcare Application Designers” workshop on behalf of the Clinical Safety committee of the Australian Medical Software Association (MSIA). This is the blurb that went out to MSIA members today:
Ensuring the clinical safety of any healthcare application is vital – but it’s hard. Not only do the economics of the industry work against it, most of the information available is targeted at the clinical users, and often isn’t relevant or useful to application designers. But it’s the designers who make the important choices – often in a context where they aren’t aware of all the consequences of their actions, and where feedback, if it comes at all, is unreliable and often unusable.
Attendees at the MSIA clinical safety workshop will work through practical examples (often real) to help raise awareness of clinical safety issues in application design, and provide attendees with a set of tools and plans to mitigate the issues. Topics covered include general clinical safety thinking, and identification, classification, presentation, and data access, migration and aggregation issues.
The workshop is sponsored by the MSIA Clinical Safety Committee, and will be lead by Grahame Grieve, who has 20 years of experience in healthcare, application design, information exchange, and also served on the PCEHR clinical safety work group.
Not all MSIA members are on the distribution list, and some of the target audience track my blog, so I thought I’d announce it here. Attendence is restricted to MSIA members, and it’s free. If you’re not on the Bridget’s (MSIA CEO) email list, and you’re interested in attending, send me an email.
We’ll be holding a FHIR connectathon here in Australia as part of the IHIC 2013 – International HL7 Interoperability Conference in Sydney in late October 2013 (around 28-30).
This is an opportunity for Australasian implementers and vendors to get practical experience in FHIR. Here’s why you should consider attending:
Realistically, this is likely to be the only connectathon held here in Australia (at least, the only one prior to the publishing of FHIR as a DSTU). The connectathon is focused around actual exchange of content, not theory (there is a place for theory, but the connectathon is not part of it). So it’s really suitable for technical staff, though we have had a few non-technical staff brushing off the cobwebs on their development skills just so that they can participate in the HL7 connectathons.
FHIR connectathons are always start with exchanging patient information, and then we build on that depending on the interests of the actual participants. We’ll be putting out an call for expressions of interest in a few months time, after which we’ll start clarifying what our actual scenarios will be. However I expect that MHD (mobile friendly version of XDS) is likely to be in scope.
In about July/August I’ll hold a 1 or 2 day tutorial here in Melbourne looking at FHIR in depth, with a focus on implementation issues. This tutorial will start with a general review of FHIR, and then look at depth at the FHIR reference platforms, how to use http tools to exercise and debug interfaces, how to convert from v2 to FHIR and vice versa, and look in detail at various models for implementing a server.
If you might be interested in attending this tutorial, drop me a line at firstname.lastname@example.org – I’m trying to get a feel for event hosting issues such as facility and cost.
I am at HIMSS 13 in New Orleans for the next few days.
I’ll be at the HL7 Booth (4325) on
The rest of the time, I’ll hanging out Booth 4219 (Dynamic Health IT).
Feel free to look me up