Stream: implementers
Topic: FHIR Benefits
Medi Harsini (Jan 06 2020 at 17:15):
Hi,
Can someone help me find a response to a question which may rarely be asked in the FHIR community yet questionable
What is the benefit of using Rest FHIR vs Open API when it comes to exposing your systems features ? Please bear in mind, I’m designing a system in a well established staffing (workforce management) system where no one uses or familiar with FHIR yet servicing to health sector purely on staff management.
Gino Canessa (Jan 06 2020 at 17:26):
Hi Medi,
The key difference is that FHIR is a standard.
Publishing your own work via OpenAPI means that other people can use your API, if they implement it. This limits interoperability to systems developing against your particular software. Every connection to your system requires someone else to spend development time and money, specific to your system.
With a standard, the theory* is that any two implementing systems can exchange information. So, you gain the benefit of an entire ecosystem of implementations to work with out of the box.
*Practically speaking, the standard isn't perfect and there are variations between implementations. That said, those variations are minor in comparison to the difference in implementing a variety of custom protocols.
Does that help?
Medi Harsini (Jan 06 2020 at 17:41):
@Gino Canessa thanks for your prompt reply
Well, that doesn’t answer my concerns fully. Let me explain more. Imagine you and 100 other more software providers wanted to work interoperable. I’m saying FHIR and design a model so complex to deliver a concept with extensions and references and code systems and so on so force. While another architect gives us a nice structured open api definition in swagger. Why would anyone want to proceed with my model over something else which is not bound to FHIR limitations ? And please don’t tell me standard because people wanted to spend less and gain more respectfully.
I can understand that you get so much benefit in clinical transaction world but not sure on staffing management world and even related financial transactions
Jose Costa Teixeira (Jan 06 2020 at 18:53):
I’m saying FHIR and design a model so complex to deliver a concept with extensions and references and code systems and so on so force. While another architect gives us a nice structured open api definition in swagger.
Not sure why it is FHIR vs OpenAPI. You can get FHIR specs into Swagger.
Jose Costa Teixeira (Jan 06 2020 at 18:55):
I do not know the context so I cannot see where FHIR is a model so complex that requires extensions for your use case but that is conceivable.
But for code systems, I guess the other architect must also use reference data, right?
Jose Costa Teixeira (Jan 06 2020 at 19:01):
Perhaps your scope is such that you are better off with a custom message, but what about
- data consistency/reuse (does your data mean the same across systems, so that you can do e.g. reporting)?
- system evolution (will you change your custom interface every time you have a new system)?
- scope expansion (are you sure you will not add anything to the scope, e.g. privacy matters, changing workflows, more coded data...)?
Jose Costa Teixeira (Jan 06 2020 at 19:03):
I define my interfaces as if I am the one that has to maintain them for the foreseeable future.
Jose Costa Teixeira (Jan 06 2020 at 19:06):
But for your concern - if you ask about "standards vs custom" to a group of people working on a standard, the answer may be biased.
Jose Costa Teixeira (Jan 06 2020 at 19:07):
If you expose more about your scope, perhaps the community can say whether this is a goof fit for FHIR or not, and you may get some arguments and experience about the possible benefits of FHIR
Jose Costa Teixeira (Jan 06 2020 at 19:09):
I think you will also get lots of experienced advice about consequences of doing custom solutions. We've all been there..
Michele Mottini (Jan 06 2020 at 21:18):
You can get FHIR specs into Swagger.
Mhh..really? Are there Open API compliant JSON schemas for FHIR?
Gino Canessa (Jan 06 2020 at 21:30):
I'm currently working on a generator... there are some tricky parts as to what you want included (e.g., extensions on every field, supported resources, profiles, etc.).
Working from the Structure Definitions makes it doable, but perhaps not trivial.
Medi Harsini (Jan 07 2020 at 01:26):
Well, only capability statement apparently and there won’t be a tool to support the structure definition nor profiles
Medi Harsini (Jan 07 2020 at 01:27):
@Gino Canessa what tool do you use for structure definition to openapi schema ?
Gino Canessa (Jan 07 2020 at 01:31):
Hi Medi, I am currently writing one. It is not quite ready for other users yet, but I can post here when it is
Medi Harsini (Jan 07 2020 at 01:35):
@Jose Costa Teixeira thanks for the details response. I’d very much like to compare FHIR vs open api on each of the items you raised above.
As per the concept, I’ve raised another issue under a different topic which has got one aspect of what it working on
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Pre-booking.20and.20pro-booking
Also, I’m very standard savy but putting my architect hat on, I’d like to ensure what I’m putting in front of 200 odd suppliers will get accepted and more importantly adopted.
Medi Harsini (Jan 07 2020 at 01:36):
@Gino Canessa thanks. I know @Michael Hansen has got a tool but it only works from capability statement. Thanks anyway
Jose Costa Teixeira (Jan 07 2020 at 08:47):
My understanding is that the comparison you're hinting at is not FHIR Vs OpenAPI but rather (FHIR+ OpenAPI) vs (custom + openAPI)
Medi Harsini (Jan 07 2020 at 10:12):
Thanks @Jose Costa Teixeira If you mean by custom, a FHIR custom resource , yes you’re right. What do you think in that case ?
Jose Costa Teixeira (Jan 07 2020 at 10:19):
No, what I mean is since FHIR Rest API can be exposed (with some manual work, I guess) as OpenAPI, the situation does not seem that you have "only" FHIR, and the other architect has openAPI. You can have openApi as well.
The debate between those architects is
#1 has a FHIR content definition, that is universal, has some infrastructure for deploying, testing, etc etc.. and can be exposed with OpenAPI.
#2 has a custom structure and can be exposed in openApi perhaps faster, because you don't have to think of standard data, versioned interfaces, test support, community, maintainability... (do I make a point yet?).
That is what I believe is the comparison. not FHIR vs OpenAPI.
Medi Harsini (Jan 07 2020 at 10:26):
Oh yes, yes.
Bear in mind that my concept is workforce management in health sector... and I’ve got one shot to convince people to follow a model. Very tricky to propose the concept on FHIR using a resource which is not originally designed to handle that scenario. For example I’m
Using appointment for booking a staff member into a shift ex. A nurse to do a 9-5 shift in a particular section of the hospital
Jose Costa Teixeira (Jan 07 2020 at 10:31):
Very tricky to propose the concept on FHIR using a resource which is not originally designed to handle that scenario.
You don't have to bend the FHIR resources. If they do not mean what you want, you can make custom resources. Not ideal, but could work.
Jose Costa Teixeira (Jan 07 2020 at 10:34):
For example I’m Using appointment for booking a staff member into a shift ex. A nurse to do a 9-5 shift in a particular section of the hospital
but in this case it seems really close (from a first reading). The nurse is planned to do the shift, so the nurse does have an "appointment" with the hospital, right?
Jose Costa Teixeira (Jan 07 2020 at 10:35):
If the semantics of the resource exclude this, we should welcome feedback.
Jose Costa Teixeira (Jan 07 2020 at 10:35):
Healthcare operations is really not a well developed area in HL7.
Scheduling, Supply...
Jose Costa Teixeira (Jan 07 2020 at 10:37):
And I think these areas deserve some love. If we look at efficiency of care from a institution perspective, this is an area with lots of opportunities.
So I would be glad to see your feedback to make the standard more complete.
Medi Harsini (Jan 07 2020 at 10:43):
@Jose Costa Teixeira I’ve spent a good one year and half on Workforce Management for NHS and so far I’ve only found so much challenge fitting the concept. Now I’ve created a simple model, but very concerned the complexity of the model scares the audiences From using it. I can certainly give so many expert as I consider myself an expert in this area as I’ve closely worked with so many workgroups. Can you please kindly have a look at the other thread I’ve created. I put three simple concept there to discuss
Medi Harsini (Jan 07 2020 at 10:43):
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Pre-booking.20and.20pro-booking
Medi Harsini (Jan 07 2020 at 10:43):
I’d love to have more feedback
Medi Harsini (Jan 07 2020 at 10:44):
but the story doesn’t end there, there are invoices and employee contracts and benefits etc. That still needs to be defined
Lloyd McKenzie (Jan 07 2020 at 13:09):
The short answer is that FHIR is targeted to healthcare- specific usecases, not generic cross-industry use cases. FHIR isn't designed to support Human Resources, Facility Management, Inventory Management, etc. Those areas are not our target scope. In some cases there can be overlap and if you're already doing FHIR for everything else, with creative use of the resources and possibly supplementing with Basic (or custom resources, depending on how much of the shared infrastructure you want to use), you can make it work.
Lloyd McKenzie (Jan 07 2020 at 13:12):
It's sounding to me that your system is targeting more generic HR functions than healthcare -specific functions. If so, you might not find FHIR a great fit. Whether FHIR is an "acceptable" fit will depend in part on whether the systems involved will also need FHIR for other purposes.
Medi Harsini (Jan 07 2020 at 13:39):
@Lloyd McKenzie thanks.
The good thing about FHIR is the governance around it. Would custom resource + openapi would be an option ? If we use custom resource we’d able to use the FHIR governance around it. Forge and Simplifier supports this but not sure about Vonk if we wanted to benefit the tooling. Having read the other threads I still don’t know if there is a tool which can convert structure definition or a profile to swagger.
René Spronk (Jan 07 2020 at 14:09):
Most tools support 'custom resources' - as does Vonk. There are two ways of supporting custom resources: the official FHIR way, which is using a Basic resource with extensions. Or the non-FHIR way which is to define your own resources. The latter allows you to do things in a FHIR-like manner, whilst officially it won't be FHIR compliant.
Lloyd McKenzie (Jan 07 2020 at 14:13):
A custom resource won't have much governance from HL7 unless the intention is to define a profile on Basic and bring that through the HL7 balloting process. If you create a truly custom resource (one not part of HL7's official list), then that option isn't really available to you. (While you may be able to get it to work with certain tooling stacks, you won't be able to make it work with all, and you'll lose out on certain infrastructure like the public test servers.)
The other option is to make a case that your use-case should become an official part of the FHIR scope because the healthcare-specific requirements mean that industry-independent solutions can't work.
Medi Harsini (Jan 07 2020 at 16:56):
Thanks you both @René Spronk @Lloyd McKenzie . I believe if I wanted to go down to the root of Custom resource my only option would be the latter solution suggested by Rene, as maintaining a big bundle with extension is outrageous.
On a different but related note, do you have experiences of a hybrid solution like defining the concept which can be implemented using the current resources and the one doesn’t using a custom resource.
Also can you suggest how to make a case against creating a custom resource for workforce management. I’d be happy to share my insights
Lloyd McKenzie (Jan 07 2020 at 17:06):
There's nothing that stops you from defining additional RESTful capabilities that aren't FHIR. And code can certainly mix and match what data it's passing around. The challenge is that much of the off-the-shelf FHIR software won't work with the custom/non-FHIR resources without tweaking.
In terms of making the case, it's really a matter of explaining how/why resource management is different in the healthcare space than it is say in the financial industry or manufacturing industry.
Medi Harsini (Jan 07 2020 at 17:28):
I think you missed the point that I’m designing all these for healthcare. Managing doctors, nurses etc ...
Lloyd McKenzie (Jan 07 2020 at 17:33):
Right. But in healthcare, there are all sorts of business functions (payroll, purchasing, etc.) that aren't healthcare-specific. We don't try to make FHIR do those things. Is there something intrinsically different about managing doctors and nurses that wouldn't apply to managing salespeople or lawyers? HL7 doesn't have the expertise (or bandwidth) to try to cover requirements that aren't healthcare-specific.
Medi Harsini (Jan 07 2020 at 17:44):
Hard to say on the fly but I’d say it is more healthcare specific than other industries. Ex. Managing specialist or nurses in a hospital is so different than managing staff in a car industry. Also qualification and specialities are healthcare related. So I’d say it is very specific and even more specific in the uk distinctively
Lloyd McKenzie (Jan 07 2020 at 17:48):
The work group to talk to is probably Patient Administration. They're responsible for Practitioner and PractitionerRole and, based on current responsibilities, would be the most likely group to take on standardization in that space. @Brian Postlethwaite
Brian Postlethwaite (Jan 07 2020 at 20:52):
Yup, what Lloyd said.
What are the areas in there you're trying to cover?
We already cover people, places, qualifications, locations, services and organizations (and the relationships between them)
And also appointments and schedules, but not recurrences (without describing each one)
A shift could be modelled using a slot, but is a small adjustment, and not really designed for shuffling things about.
The slot was more intended to cover availability, which a shift kind of is. Alternately a schedule could narrow down to a shift too. (and have lots of those)
Medi Harsini (Jan 07 2020 at 21:42):
@Brian Postlethwaite thanks.
To avoid putting too much info here, would you kindly comment on https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Pre-booking.20and.20pro-booking
Medi Harsini (Jan 07 2020 at 21:44):
Please bear in mind I’ve already done what it’s been posted there using ServiceRequsat=> Booking => Encounter but the model looks complex for none FHIR users. It doesn’t read well, you know
Medi Harsini (Jan 07 2020 at 22:42):
@Brian Postlethwaite A shift status once its vacant, its sent to a system called bank system to be fulfilled by someone. That request is called vacancyrequest which I used service request for. Then the bank system would find a suitable person and book it to that shift, I’ll use appointment for that. And once the shift is completed there is a timesheet elements which I’ll use encounter.
Medi Harsini (Jan 07 2020 at 22:43):
More info and discussion is in that thread. But then once the timesheet (encounter) is submitted, the bank system should invoice the hospital or issue a payroll which I haven’t done and not sure what resource to use
Brian Postlethwaite (Jan 07 2020 at 23:55):
Payroll would be outside I'd expect.
Medi Harsini (Jan 08 2020 at 00:15):
@Brian Postlethwaite Any comments on the rest is appreciated
Frank Oemig (Jan 08 2020 at 07:41):
Well, some years ago, before FHIR, we applied the HL7 Standard v2.x to the hotel domain - Hotel Level 7 :wink:.
If you translate guest to patient, Check-in to admission, Check-out to discharge, service requests to order entry, minibar consumption to DFT, etc. it works fine.
It is about mapping the business domain model to a technical representation. FHIR is fine for that purpose.
Jose Costa Teixeira (Jan 08 2020 at 08:06):
In some cases this may or not be possible, but @Medi Harsini this is one thing that I see as a huge advantage in FHIR (and standard-based approaches):
in FHIR we have information models, such that we can check whether a concept can be reused or not, or can be adapted/translated to another model or industry. And if we do adapt/translate, the whole platform supports it because the standard relies on other standards.
If you do a single-purpose solution, every expansion may prove to be a challenge. But your other architect must know that and have experience with scope creeps.
Josh Lamb (Jan 08 2020 at 16:14):
This is an interesting thread. My understanding is that putting something into a FHIR format does not guarantee interoperability. To truly be interoperable you need to create resources and interactions that are consistent with an Implementation Guide. The IG will inform meaningful interactions in a way that unconstrained resource definitions will be unable to do. Using @Frank Oemig's example, no other hotel system would be able to know that a Patient is actually a guest and admission is actually a hotel check-in without some agreed upon system for interactions/data quality.
Lloyd McKenzie (Jan 08 2020 at 16:21):
Implementation guides are indeed key to interoperability. One of FHIR's strengths is the set of mechanisms for doing that profiling, validating against those profiles and publishing and sharing that documentation.
Frank Oemig (Jan 08 2020 at 16:30):
Well, the hotel example is a little bit extreme, but ok and works. Ok, both sides have to implement the same spec and agree on it of course.
FHIR is a framework that helps to achieve interoperability. But as Lloyd states, without implementation guides it will not work. But even with IGs you may end up without interoperability if remaining freedom leeds to different - and then imcompatible - interpretations.
So, if you create instances according to one IG and everything is fine, it may end up with missing interoperability according to another IG. If you have to create resource instances obeying to different IGs, those must be compatible, otherwise ...
This is the reason why I argue in favor of profile hierarchies.
Concerning information models, they are coming from a business domain and should reflect the needs and requirements. You can translate those into different technical representations, and also have different representations in FHIR.
Grahame Grieve (Jan 09 2020 at 22:59):
Are there Open API compliant JSON schemas for FHIR?
yes. it's a switch on the json schema generator. but there are many problems in JSON schema...
Edward (Feb 14 2020 at 20:34):
Does anyone know if there's any influences of the OData Spec on FHIR? going through some of the documentation, there's references of OData in the spec. OData support would really enable BI tool enablement of FHIR API's...
Gino Canessa (Feb 20 2020 at 17:30):
Edward said:
Does anyone know if there's any influences of the OData Spec on FHIR? going through some of the documentation, there's references of OData in the spec. OData support would really enable BI tool enablement of FHIR API's...
Hi Edward, sorry for not replying sooner but the new version (2.78.5740.721) of Power BI Desktop includes a FHIR server connector for native access to FHIR servers. Documentation can be found here.
Last updated: Apr 12 2022 at 19:14 UTC
