What is ‘FHIR’ and why should you care?

FHIR is the latest standard to be developed under the HL7 organization. Pronounced ‘Fire’ , FHIR stands for Fast Healthcare Interoperability Resources.

I think it’s the most interesting standard to have come out of HL7 since the original HL7 protocol. In my opinion it’s the only one which has a chance of becoming a widely implemented standard.

Version 3 HL7 was a technically disruptive technology that was lacking an equivalent disruptive business opportunity or need in the market. In blunt terms it did not help anyone make money or save money which was why until government agencies started to mandate it’s use, it was dead on arrival.

That was the main point I put out into the standards community with a provocative blog article I made 2 years ago – The Rise and Fall of HL7.

I didn’t really expect the article to have much impact. But surprisingly it did. WebAds_6ReasonsWhyYouNeedAModern_300x250

Barry Smith picked up and re-published it and it caused some waves of debate within the healthcare standards world. I hit a chord with what many people were thinking but were uncomfortable to talk about publicly.

It acted as a catalyst in creating the HL7 Fresh Look task force and from that effort emerged the new FHIR project spearheaded by Graeme Grieve.

To me FHIR looks very promising. It’s hard to predict if it will be successful but I think the approach has value. Technically is starts from a sound foundation:

It’s a more granular way to exchange data without the rigid workflow of traditional HL7.
No overhead of SOAP and other nonsense by using a straightforward RESTful style approach.
High emphasis on conformance and reference implementations, connectathons etc. as part of the core process
It focuses on hitting 80% of the common use cases rather than the 20% of exceptions (80/20 rule)

But more important than the technical factors, FHIR addresses some real needs in the market. It passes the smell test of enabling people to make money and save money. These are the drivers:

Mobile healthcare applications and the cloud
Medical device integration
More flexible custom workflow

That’s what’s exciting about FHIR – this standard really could be useful and actually drive new efficiencies. For vendors it represents an opportunity to offer more value to their clients and build new revenue streams. For end users this offers ways to streamline and improve patient care and drive down bottom line costs.

FHIR is like HL7 Version 2.X in that it actually has the potential to solve a real need that exists in the market. That’s the foundation of making a successful standard. FHIR could help make money and save money. That is essential if you want a standard to be adopted.

That’s why I am putting my company behind and supporting the FHIR standard. You’ll be hearing a lot more about FHIR and what it means from myself and my team over the coming year. Anyway – sound out – what are your thoughts? What do you think about the new FHIR standard?

Mar 3, 2013Eliot

Comments: 38

Shamil
March 5, 2013 at 11:07 am
What’s the difference between FHIR and v2 Z-segments then – in terms of
Mobile healthcare applications and the cloud Medical device integration
More flexible custom workflow?

– From LinkedIn: HL7 Interface Professionals group discussion
Reply Cancel
Jayant
March 5, 2013 at 12:39 pm
Standard looks promising. V3 also looked promising at first instance but was surely a complex standard.

Do you think FHIR announcement will hit V3 projects/solutions/products?

– From LinkedIn: HL7 International group discussion
Reply Cancel
Eliot Muir
March 5, 2013 at 1:46 pm
Very much so – let the games begin! My opinions of V3 are well known. I disliked the whole concept of V3 from the start – I used to go to all the HL7 working group meetings but I lost interest. With FHIR I see something worthwhile that actually has value and I think I will make the effort to join my some of my staff and attend again.

There is enough complexity in the domain issues of healthcare data without adding layers of unnecessary technological complexity to compound it all.

My first meeting at HIMSS yesterday was getting breakfast with Graeme Grieve. When I get some time I will blog about it but I am even more excited about what FHIR can do.

A lot of people that were involved in V3 are now moving over and backing FHIR. That’s a really good thing. There were a lot of passionate bright people involved in the creation in V3 – having those people add energy and momentum to FHIR is great. It’s like when you want to bring about change in any organization – it’s positive to include people and make them part of the solution.

FHIR is at it’s early stages – I’ve been having fun talking to some our business partners and explaining to them where I think FHIR fits and how it creates new opportunities.

– From LinkedIn: HL7 International group discussion
Reply Cancel
- Jayant
  March 5, 2013 at 6:48 pm
  True, it is exciting, Referring your blog, I have also created a category for FHIR in my blog for my readers and have posted first article today. will kep an eye on FHIR development & your posts on it.
  
  http://www.j4jayant.com/articles/fhir/20-fhir-a-fire
  
  – From LinkedIn: HL7 International group discussion
  Reply Cancel
  - Eliot Muir
    March 6, 2013 at 11:00 am
    Yesterday I spoke with the CEO one of our partners Snap Medical – they were anticipating 50% of their integration was going to be HL7 and 50% web based APIs – in fact it’s more like 80% of their integration is using web based APIs. Those APIs are unique to each application – some are SOAP based, some RESTful. Often the error messages that come out of these APIs are not that easy to understand.
    
    One way or another web based API integration will replace HL7 integration. I wouldn’t get too worried about whether it’s trully ‘REST’ etc. It’s just the general idea of using JSON/XML over vanilla HTTPS and the ability to get random access to data is just a lot more flexible for doing integration.
    
    Consider the most simple case of having an EMR that has a simple API to attach an arbitrary note to a patient. You can solve so many different problems with a simple API like that – push a note in with content from a SAP system, or an accounting system – a whole rich ranges of uses from IT systems which know nothing about HL7.
    
    HL7 2.X is becoming far less important. FHIR is the only chance the HL7 organization has to give value and remain relevant in the healthcare integration space. It’s largely going to be a question of how quickly the FHIR standard can be matured and get adoption.
    
    If it doesn’t happen quickly then what will happen instead is you’ll see the process happen organically in the market. There will be an EMR that get’s significant marketshare that has an API – if they develop an eco-system of applications that can integrate with that API then the incentives for their competitors to make APIs which are compatible with that API so they can access that eco-system of compatible products.
    
    It’s like all the games with Android taking over the Java APIs and Sony implementing Microsoft’s DirectX’s APIs.
    
    Either way we will be headed to at some point, at some time to where we get some fairly standard healthcare web based APIs which are likely to be REST like since they are the simplest to implement.
    
    FHIR is easy to implement from what we’ve seen. Rolim one of my team was able to throw together an implementation and pass the connectathon with only a couple of days of effort.
    
    The race will be whether or not FHIR can be brought into the market fast enough to get adoption before defacto standards emerge.
    
    – From LinkedIn: HL7 International group discussion
    Reply Cancel
    - Jayant
      March 7, 2013 at 1:54 pm
      I think even after maturity, for many years FHIR will have to work together with HL7 v2.x & v3, this will be critical time period for all software vendors FHIR adoption will surely set new trends in this area, till then we will see many conversations & knowledge sharing on open forums which will eventually help all of us.
      
      – From LinkedIn: HL7 International group discussion
      Reply Cancel
    - GreggT
      April 11, 2016 at 9:26 am
      > a simple API to attach an arbitrary note to a patient
      
      Help me understand the end goal here… Without context, how would the user understand which notes this new note overrides or augments? How do you prevent a huge pile of notes that have no relationship to each other? How does one integrate the structured information seen in assessments (blood pressure readings, med dosage) with the info in the note?
      
      It seems like a “simple” API would create a mess, which impacts medical safety in that a new doctor is overwhelmed with data, which hides information.
      Reply Cancel
      - Eliot
        April 11, 2016 at 1:04 pm
        Fair comment.
        
        Doctors and other clinical experts never would be interacting directly with any web API and for that matter they wouldn’t have been working with HL7 messages either. Interfaces tend to be the domain of technical specialists.
        
        For the technical specialist the pro’s of web apis is the ability to get random access to the complete data model of an application. But having said that all APIs are not equal. As the web standards world has progressed there has been an explosion of more complicated ways to getting APIs to authenticate which can be a bit intimidating.
        
        There are APIs like Athena’s web api which isn’t bad in that it’s well published – although it’s not reached the level of the wider world where you can get a real instance of Athena to play with along with it’s API.
        
        As for FHIR – well it’s a bit like HL7 all over – large vendors can be vague about how they support it or how they have interpreted it. For applications like Athena which already have well defined APIs there is not much to gain but pain from having another layer like FHIR on top of it (and who pays to develop that?).
        
        So at the end of the day you just have to look at the practical integration problems you have at hand and what your options are for getting data in and out of a given application taking into account your licensing rights. Most EMRs want some type of licensing payment for whatever APIs or feeds they expose to you. Sometimes you have resort to running reporting applications on batch and having them drop out comma delimited files (CSV) and get your data that way.
        
        Web APIs can be challenging for someone from an HL7 background because of the fact that often you do have to go and gather all the related information.
        
        The real world is a place where you have to solve problems with limited budgets and make so with what you have 🙂 and deal with layers of technology from many different eras and trends. All good fun!
        Reply Cancel
Patrick
March 5, 2013 at 2:00 pm
I am definitely for the RESTful vision behind FHIR and it being a solution that addresses problems rather than the HL73 initiative that was a solution looking for a problem to fix. Hopefully FHIR has legs.

– From LinkedIn: HL7 Interface Professionals group discussion
Reply Cancel
Jens Kristian
March 5, 2013 at 2:36 pm
A more pragmatic and less invasive approach is currently under way by the open source community @ http://hl7api.sourceforge.net/hapi- hl7overhttp/index.html – it has however not yet been proposed as a standard.

– From LinkedIn: HL7 Interface Professionals group discussion
Reply Cancel
- Eliot Muir
  March 5, 2013 at 7:13 pm
  Hi Shamil – your question deserves a longer more complete answer. And I doubt this brief comment will make much sense. Z segments in V2 are a kind of tacky-on within the format. It’s an after thought which doesn’t extend the data model in a graceful manner.
  
  If you think of data as being properties on concepts then a better standard is one which allows data extension in a natural manner which fits with the core data. For instance if you think of contact information as natural collection of data then being able to add to that collection – properties like say GTalk, Skype, Jabber twitter is useful since their context makes it clearer what the new non-standard data is.
  
  That’s probably not a great explanation but hopefully that helps.
  
  Jens thanks for sharing the information about the HTTP transport for V2 – that definitely does have value – it provides a mechanism to get V2 data through firewalls which is nice. It has the most value if a variety of technologies can be used to implement it since it then it allows a hospital to use their own integration technology to communicate with a business partner securely over the web.
  
  FHIR is more disruptive I totally agree, but it comes with more value that goes beyond what V2 HL7 can offer. I’m short on time this week but a old blog post I wrote touches on some of the risks in not taking the opportunity to re-examine old assumptions as technology progresses:
  http://blog.interfaceware.com/hl7/version-2-hl7-json-answer/
  
  – From LinkedIn: HL7 Interface Professionals group discussion
  Reply Cancel
Shamil
March 6, 2013 at 9:15 am
It is not that I don’t understand FHIR, in fact I’m keeping eye on all changes that’s going on around this (hopefully) upcoming standard. It is more about my skepticism that
DELETE /user/2 is something _revolutionary_ comparing to
GET /user_delete?id=2
on the one hand, and too many devils are swarming in details on the other (privacy and security is one of the issues).

While software development companies may benefit by jumping in earlier and building complete solutions at the time when FHIR is approved as the standard for new users, it will be hard to convince existing HL7 v2/v3 customers to abandon all big $$$ spent on current infrastructure and switch to a new platform. You are aware about HIAL in Canada, as an example, aren’t you?

And by correct (or incorrect) use of V2 Z-segments it is easy to replicate almost everything that FHIR offers nowadays including use of RESTful interface or something that Jens mentioned earlier.

Again, I’m not arguing against FHIR, just showing that there are too many steps to go and there are other solutions available.

– From LinkedIn: HL7 Interface Professionals group discussion
Reply Cancel
- Jason
  March 6, 2013 at 10:16 am
  I don’t know a thing about FHIR, but I do know this: No one implements anything unless it solves more problems than it creates within the time constraints of their current planning horizon. What problems do people choose to solve? The one’s that have for them become unmanageable. What solutions do they opt for? The one’s that are easiest to implement. If FHIR solves an unmanageable problem and is easier to implement than the alternatives, then it has promise.
  
  – From LinkedIn: HL7 Interface Professionals group discussion
  Reply Cancel
  - Jens Kristian
    March 6, 2013 at 3:17 pm
    @Jason I agree. And I guess that is exactly why the HAPI framework proposal has only changed the transport layer part of the protocol and nothing more. This minor change leaves all business logic unchanged but eases firewall issues, malformed encoding and enables a more simple secure communication model, simply by using HTTP instead of MLLP.
    
    I haven’t yet read much about FHIR. All I know is that it is REST + XML based which isn’t as arcane as MLLP + ER7. However, both technology constellations works. Whether FHIR brings something new to the table or not, I’m unable to answer.
    
    – From LinkedIn: HL7 Interface Professionals group discussion
    Reply Cancel
    - Grahame
      March 13, 2013 at 11:21 am
      @Jens – if the problem was simply transport/rest, then sure, v2 + rest would be the way to go. And many people in v2 land often say to me, why not just do that? But the problem is much more than merely rest and transport – it’s to do with content, and how it’s defined and made usable. Because v2 based business logic, while widely adopted, hasn’t got the legs to take us into the future.
      
      – From LinkedIn: HL7 Interface Professionals group discussion
      Reply Cancel
      - Eliot Muir
        March 13, 2013 at 7:23 pm
        @Grahame – Agreed V2 is too tightly coupled to some very specific work flows. The data is tied together in a weird inflexible manner – V2 is certainly not normalized and it lacks natural extensibility for changing requirements with new data (Z segments are a cludge).
        
        In the EMR space in doctors practices HL7 integration has already become the exception rather than the norm. All the different EMR vendors like Greenway etc. are encouraging integration through their own web service APIs. The quality of those APIs vary from EMR vendor to vendor – some are RESTful, some use SOAP, quality of error messages coming varies greatly (often not great). Still these APIs are easier to integrate with than HL7 V2. Each EMR vendor is trying to create an eco-system of compatible products that can complement their products – that competitive process will mean that there are competitive incentives for other EMRs to try and subvert another vendor’s eco-system by making their own web service APIs more or less compatible.
        
        Much the same way Google leveraged Java’s ecosystem by making their implementation of the same APIs for Android mobile development or Sony implementing Microsoft’s DirectX in the Play Station 4.
        
        FHIR is the last opportunity for HL7 to remain relevant as a standards organization in healthcare. If FHIR is executed well then it becomes an attractive API for EMR vendors to implement then it may be able to compete well with the organic commercial process that is happening already. I am optimistic – would have been better to had FHIR happen earlier but HL7 still carries a lot of weight in government circles. Also FHIR doesn’t take much resources to implement – that’s going to help the standard.
        
        – From LinkedIn: HL7 Interface Professionals group discussion
        Reply Cancel
Rick Kuchan
March 6, 2013 at 7:08 pm
Just saw Graham’s presentation on FHIR at HIMSS13. Rumor is there are significant early adopters implementing already , for example interface engine vendors. This even though a standard may be still a couple of years out. So whatever the risks, they are deemed manageable enough, up to some point.

FHIR is tied to the RIM, and in my view is an alternative to, in parallel with, v3 CDA/CCD. It also has broader applications. The cost/benefit make it irresistible by comparison. If it works, what would prevent it from replacing CDA?
Reply Cancel
- emuir
  March 6, 2013 at 7:16 pm
  Yes I see it easily replacing the CDA standard. Hands down FHIR is much more versatile and useful.
  Reply Cancel
Frédéric
March 7, 2013 at 11:09 am
Very interesting perspective on FHIR. I will follow this new standard closely as it looks promising. It will be interesting to see how it evolves over the next few years. We had some interesting discussions on FHIR at the last Infoway’s Fall Partnership conference.

– From LinkedIn: HL7 Interface Professionals group discussion
Reply Cancel
Mark
March 11, 2013 at 2:30 pm
If V3 has the complexity etc. issues, is this why IHE, and if we have IHE and V3, plus DICOM, etc. why do we need yet another interoperability standard like FHIR?

– From LinkedIn: HL7 International group discussion
Reply Cancel
- Jayant
  March 11, 2013 at 2:15 pm
  IHE is not an interoperability standard but a set of guidelines/specifications to promoe coordinated use of standards(DICOM, HL7 etc).
  
  V3 complexity has nothing to do with IHE, it has specifications for HL7 V2.x as well DICOM is used for medical imaging & it is different than HL7 & FHIR.
  
  With FHIR, HL7 wants to target new markets like mobile, web & address limitations of V2 & V3. It uses latest technical specifications and built based on resources from a very popular concept called REST… supports data formats like XML & JSON.
  
  – From LinkedIn: HL7 International group discussion
  Reply Cancel
  - Eliot Muir
    March 12, 2013 at 11:00 am
    IHE covers a very narrow set of use cases with some very specific work flows. It has some value, but it doesn’t fix any of core problems in HL7 and DICOM. It doesn’t provide a quick easy way to hook up your healthcare information systems to non healthcare systems like your accounting system or your Sharepoint wiki etc.
    
    The easy way to think about it is that a standard like FHIR (if executed correctly) should allow one to have a simple granular call that allows one to attach an arbitrary note to a patient. Once you have the simple API available it’s very simple to take data from any number of sources which don’t have to be tightly coupled or ‘HL7 compliant’ (or for that matter FHIR compliant).
    
    Talking about DICOM – I had breakfast with Graeme Grieve on Monday morning and getting rid of technical debt and complexity associated with DICOM is another attractive aspect of FHIR. Moving images, ECG data etc. treating them just as another type of MIME resource isn’t complicated.
    
    – From LinkedIn: HL7 International group discussion
    Reply Cancel
    - Mark
      March 17, 2013 at 2:02 pm
      Does all this mean we should get out our “V4 NOW!” buttons?
      
      – From LinkedIn: HL7 International group discussion
      Reply Cancel
      - Eliot Muir
        March 17, 2013 at 1:03 pm
        Lol! I think it would be a branding mistake. V3 had such a negative rep. FHIR is a good name for the standard – it’s not an incremental evolution of V2 and V3.
        
        The big competition in the market for FHIR is not V2 or V3. The real competition is from defacto web service APIs emerging through organic competitive processes between EMR vendors. As I have mentioned in other comments – Web service API integration has already largely replaced HL7 integration in the practise office EMR space.
        
        The trend to this type of integration approach is inevitable – it is merely a question of what route we get there. If the HL7 organization wants to be relevant and healthy then it would be prudent to put enough resources into FHIR to make the standard good enough quality to attract adopters and make it successful.
        
        I saw this trend happening years ago which is why I made sure we were positioned to be a good solution for either kind of integration. Integration in healthcare is so much broader now compared to when it used to be just V2 HL7 and DICOM. We all have to reinvent ourselves now and then in technology.
        
        – From LinkedIn: HL7 International group discussion
        Reply Cancel
Piers Hollott
March 12, 2013 at 5:51 pm
Great article, and kudos for helping get the ball rolling. Two things are also worth mentioning:

Grahame gifted FHIR to HL7 Int on the condition that it become an open standard specifically to support both implementers in the mobile and social world and countries with lower GDP, and HL7 has agreed to this condition.

FHIR is REST-enabled, and a robust REST solution can be implemented; but FHIR still supports and is not at all dismissive of SOA.

Grahame did a really good Google+ Hangout with Tim Cook recently:
https://plus.google.com/111266059548540805002/posts/5oaeZtYFbTT
Reply Cancel
Eliot Muir
March 12, 2013 at 6:57 pm
FHIR is definitely accessible – it’s an easy standard to implement. I had a nice talk with Keith Boone (aka Motorcycle Guy) about FHIR. I think what Keith liked the most about FHIR is he walked into a connectathon with no code and at the end of the event walked out with a working implementation.

For us it’s a great opportunity also. For starters Iguana is an exceptionally easy platform to implement FHIR on top of. It took one of my architects Rolim all of an half a day to implement FHIR within Iguana.

The bigger benefit is what FHIR means for integration across healthcare in general.

With FHIR enabled devices and applications it becomes less expensive to integrate and so organizations will find more projects viable that involve integration than they would have without FHIR.

That’s a golden opportunity for anyone that makes their living from integration. If you are an IT person it means more projects that have value for your clients and/or your organization.

For integration engine vendors like us with Iguana it means that more integration projects occur and there is more value for integration engines. Integration engines provide additional value in giving fast implementation, visibility into operations (important when you have literally thousands of interfaces), workflow orchestration and then exchanging data with legacy systems and non-healthcare systems.

It nice to see HL7 finally working on a standard that implementors can actually get excited about. It’s been a long time coming.
Reply Cancel
Piers
March 13, 2013 at 6:33 pm
Another huge win as FHIR becomes more widely used is that implementers and vendors in Canada, Australia, the UK and the Nederlands will have more to talk about with implementers and vendors in the US, and hopefully with more buy in from other countries.

I think a key factor here will be IHE, and this is where John Moerkhe’s involvement with FHIR is going to be important in defining how to ensure privacy and security. He writes about his own connectathon experience:
http://healthcaresecprivacy.blogspot.ca/2012/09/the-magic-of-fhir.html

– From LinkedIn: Health Level 7 Group discussion
Reply Cancel
Jens Kristian
March 14, 2013 at 10:44 am
Well – HL7v2 might be ambiguous – but it is also the most widely used protocol. Combined with the IHE profiles, I would give it an extra shot. I agree that FHIR might be the future of HL7 but I still haven’t seen any samples of it other than the mini-connectathon.

– From LinkedIn: HL7 Interface Professionals group discussion
Reply Cancel
Dr. Satish Khune
March 22, 2013 at 4:33 am
I think we should get a more precise answer to “What is FHIR?” rather than “Why we should care for it?”
Reply Cancel
Eliot Muir
March 25, 2013 at 2:12 am
See:
http://wiki.hl7.org/index.php?title=FHIR
Reply Cancel
- Dr. Satish Khune
  March 29, 2013 at 5:41 am
  Thanks! That was really useful.
  Reply Cancel
  - emuir
    March 29, 2013 at 9:37 am
    You’re welcome!
    Reply Cancel
Garry Christensen
March 25, 2013 at 6:31 am
I’m really pleased FHIR is beginning to make an impact. I’ve been fortunate to attend some seminars in the past 12 months where Graham Greive has been a major contributor. I am of the opinion that FHIR represents the next step forward in healthcare communication, providing a real-world solution where HL7 V3 seemed to be idealistic or simply acedemic.

I’m relatively new to Iguana but I can see that it provides an incredible powerful development tool for implementing FHIR. I’ve already seen Rolly’s article for interacting with FHIR archive and its a great place to start understanding the actual implementation. The combination of XML/JSON support and the power of LUA makes it all so simple.
http://community.interfaceware.com/index.php/topic/50-connecting-to-fhir-patient-using-restful-web-services/

The next step is using Iguana to service the FHIR queries. Again, Translator makes the database and XML/JCON encoding quite straight forward. There’s already a web interface but I don’t know if it will be up to the task of providing full enterprise connectivity. It also need to be able to implement the unique URL that each resource requires.

It may be too early in the planning process yet but I’d be interested to hear your thoughts.
Reply Cancel
- emuir
  March 25, 2013 at 4:27 pm
  We already have customers using Iguana’s web service capabilities in very punishing environments. Enterprise environments are not as demanding as internet scale services. If you really had something that demanded more then it’s possible to put a load balancer in front of Iguana – much the same way people deal with node.js and so on in huge volume applications – like Linked In’s mobile backend. Healthcare users don’t come anywhere near this type of scale and given what ancient platforms many high volume healthcare sites are using I don’t think Iguana will have any trouble – Iguana is fast.
  
  Funny – just chatting with Roli (Rolim) and the Lua version of node.js looks to be about 3 times the speed of node.js – so it’s all good – we’ve picked a solid platform and we have unique environment with the translator to make Iguana the best environment to implement FHIR on.
  
  We will tweaking things to allow giving a unique URL for each resource. It’s a very small change.
  Reply Cancel
  - Garry Christensen
    March 25, 2013 at 9:35 pm
    Thanks Eliott. Sounds like you have it well in hand. I look forward to seeing how it all works, and getting involved in some local connectathons using Iguana.
    Reply Cancel
Tony Julian
April 2, 2013 at 2:27 pm
Once the U.S. GOvernment settled on CCD and CDA-2, I dont see CDA disapearing anytime soon.
Reply Cancel
Jesus Mena
September 2, 2013 at 9:22 am
There’s something here that caught my attention. The author estates that HL7 v.X didn’t help anybody to make money, but I can see lots of companies making profit out of it; people who help you understand HL7, people who develop engines for messages exchange… I do see how HL7 helps people to make money. The problem is why these people are making money: because of a very off, odd, old, concept of information structure. Fields with positions? it is just terrible to deal with something like that, when you could use something like XML or even objects instead.

Some people here point at the REST thing of FHIR as the key thing, when actually it is not. The key point here is that in FHIR you have well defined objects (or collection of attributes), and you only need to say what you want to do with this objects. As far as I know FHIR can be implemented in whatever way you want, no need of REST, it can be WS, or whatever API you want.

REST APIs can help to cleanly implement the idea, but you don’t need them. As some other person commented before, there’s no advantage of using /object/id over using object?id=id.

Now I have to work on a project that needs to communicate with an already existent SW that uses HL7. I need to choose what to go for. And honestly, I have no time for twisted message headers, parts, field positions and so. If it entirely depended on me, I would go for a FHIR inspired REST API. If it becomes a standard in the future, the better. If not, at least we saved money and time trying to understand an awkward and outdated way of transferring information.
Reply Cancel
Eliot
September 4, 2013 at 5:51 pm
To clarify Jesus, my points were that Version 2.X of HL7 was a much more effective protocol in serving a useful economic purpose vs. HL7 3.x.

I’d agree with you that a modern RESTful based API using JSON or XML is a lot easier to work with than HL7. 2.X HL7 was an improvement over what came before it – adhoc CSV file dumps, fixed width exports etc.

The biggest issue with integration is the fact that the effort has to be repeated N times for N sites. That’s the whole value of using an interface engine rather than hard coding all this logic directly into your product.

Are you working on adding an interface to a specific product or integrating a 3rd party product for an end user?
Reply Cancel

What is ‘FHIR’ and why should you care?

Leave a Reply Cancel reply

Eliot

Subscribe to blog

Subscribe to our integration blog

Subscribe to our integration blog