Great presentation man! Having a non-medical background myself I am looking into FHIR a relative long time as a low-code developer, but you starting to convince me that open EHR is the way forward for realizing and building medical apps. Thanks a lot!
For 3:43, There could be recommended valuesets published in the IG's to make sure the country uses the right set of codes and the essential software developers could get informed of it.
I'm looking forward to more videos. I need to get up to speed on FHIR for a company project. This is excellent work and very helpful to understanding FHIR and the larger system it exists in. Thanks much!
More and more convinced that openEHR is the right tech for semantically meaningful structured data. It's just the sheer number of clinical data models defined in openEHR and the fact that the data points have to be cut out from a maximal definition to define practical usable artifacts. FHIR takes the opposite approach and goes with profiling leading to 100 different FHIR profiles that are not even interoperable with each other.
I appreciate your response to my query and it will take me some time to fully analyze and understand it. I believe your conclusion aligns with what a mutual acquaintance, and hopefully a new friend (@PabloPazosGutierrez), discussed with me earlier this morning. I sincerely appreciate you sharing what you have learned.
This is an excellent presentation on limitations on FHIR and Open EHR versatility. Here in the US there is an effort to migrate towards FHIR. Software vendors are busy promoting their own interest . The whole EHR industry and interoperability have taken off on uncharted sea. Complicating the situation is limitations of the US health care data base. Simplification and utility of database is of paramount importance.
Hi Sid, Great findings! Do you still feel that OpenEHR is better than FHIR? I am interested in doing work on Hospital Mgmt App. So appreciate your input.. Thanks!
Interesting observations on FHIR and OpenEHR. In OpenEHR, taking the example of blood pressure coding, what happens if a country does not use SNOMED CT but some other terminology? Does the healthcare system now have to change to using SNOMED CT?
Then the entire "ideal world of healthcare interoperability" is ruined. That's why FHIR is a framework that each jurisdiction may constrain or extend. On top of that, there are local extensions to both LOINC and SNOMED CT.
Have you seen the OpenEHR REST API? You might want to check that out. I'm guessing you're going to like it. By the way, excellent channel. Please keep it up.
I disagree with your assessment of why FHIR is limited by the 80:20 rule. First, the 80:20 rule means that FHIR seeks to implement at least 80% of a given resource. 20% remains unique to a country or jurisdiction. This is because different countries have some unique requirements that are not the same as those in other countries and as such you can’t force them to adapt the same profiles - so FHIR is flexible. This also allows developers to build applications based the requirements of the profile they are given. Also as an app developer, you could build an app with as many blood pressure characteristics as you want using FHIR if your customer wants to do that - it’s all dependent on the profile you are given.
Main difference is having a base Reference Model that ensures that everyone at least works with the same base rules. Extension mechanism is very powerful, but can easily get out of hand fast
@@medblocks I can understand the desire to write an application once and forget about it. I think that it might be a little restrictive since you might not always be able to cover every thing a customer might need. Am not familiar with OpenEHR so I might be missing something. However, I doubt that it is possible that it would cover everything every one in the world would ever want to cover for each of the resources. Therefore the extensions of FHIR become really powerful.
@@medblocks This makes OpenEHR too inflexible to use in practice. For example, in our application, we need to include the patient's age when the measurement was taken with each data point. We are specifically not allowed to include the dates, and the patient birthdate is not allowed in the data. This was not anticipated in the FHIR standard and is not present in OpenEHR. When OpenEHR matures to the point FHIR has, it will take a lot of coordination to get this added, delaying the project by years. However, with FHIR, we can use the age-at-event extension (github.com/ncpi-fhir/ncpi-model-forge/blob/6656a2c6550a3000623cb43c3d9c6f1d06aef7d5/site_root/input/resources/extensions/StructureDefinition-age-at-event.json). Right now, this means that there are a lot of potential representations that application developers need to consider. However, as time goes on, the community will converge on a standard. The US Core Standards people will negotiate with the NDHM to create convergent implementation guides. Though I'd love to be proven wrong, OpenEHR is probably yet another incompatible standard, not the one unifying standard that will take care of everyone's use-cases. See xkcd.com/927/
@@medblocks While I agree with your disagreement to the point above, I disagree with your general argument. The lack of Ambiguitiy stems from the level of abstraction between the two - with OpenEHR being more abstract. Everything is more or less an observeation. Dealing with specifics mandated locally and deeper syntactic interoperability on a standardized level as opposed to delegating them the the implementer makes sense on the long term. You are right in that the standardazation work is excrutiatingly slow.
Hi iam very new to fhir my doubt may be silly please dnt mind, we are posting our patient details and it generates an id so we can get what ever we posted iam good upto there how does it help in real time to the providers and patients how they use this data... can we get data from another provider of patient who came from that hospital iam little bit confused iam imaging like get is like we get data from another providers if we can get how? post means we post our data to fhir server which can be accessed by others iam I crt
@@medblocks how smart fhir works? we created observation vitals resources they need to know our ids know to call get or post sorry for bothering you so much how smart fhir knows those
Great presentation man! Having a non-medical background myself I am looking into FHIR a relative long time as a low-code developer, but you starting to convince me that open EHR is the way forward for realizing and building medical apps. Thanks a lot!
For 3:43, There could be recommended valuesets published in the IG's to make sure the country uses the right set of codes and the essential software developers could get informed of it.
I'm looking forward to more videos. I need to get up to speed on FHIR for a company project. This is excellent work and very helpful to understanding FHIR and the larger system it exists in.
Thanks much!
Sidharth, in the video "The Problem with FHIR and why openEHR might be better", has your opinion changed over time regarding this topic?
More and more convinced that openEHR is the right tech for semantically meaningful structured data. It's just the sheer number of clinical data models defined in openEHR and the fact that the data points have to be cut out from a maximal definition to define practical usable artifacts. FHIR takes the opposite approach and goes with profiling leading to 100 different FHIR profiles that are not even interoperable with each other.
I appreciate your response to my query and it will take me some time to fully analyze and understand it. I believe your conclusion aligns with what a mutual acquaintance, and hopefully a new friend (@PabloPazosGutierrez), discussed with me earlier this morning. I sincerely appreciate you sharing what you have learned.
Excellent comments, Sidharth.
This is an excellent presentation on limitations on FHIR and Open EHR versatility. Here in the US there is an effort to migrate towards FHIR. Software vendors are busy promoting their own interest . The whole EHR industry and interoperability have taken off on uncharted sea. Complicating the situation is limitations of the US health care data base. Simplification and utility of database is of paramount importance.
Hi Sid, Great findings! Do you still feel that OpenEHR is better than FHIR? I am interested in doing work on Hospital Mgmt App. So appreciate your input.. Thanks!
Interesting information...Thanks for sharing...May i know that SNOMED CT implementation course that you have been taking?
@@medblocks thanks
Hi Sidharth, can you please let me know how we can add Patient related data(like DNR status or an observation) in a FHIR Resource?
Interesting observations on FHIR and OpenEHR. In OpenEHR, taking the example of blood pressure coding, what happens if a country does not use SNOMED CT but some other terminology? Does the healthcare system now have to change to using SNOMED CT?
Then the entire "ideal world of healthcare interoperability" is ruined. That's why FHIR is a framework that each jurisdiction may constrain or extend.
On top of that, there are local extensions to both LOINC and SNOMED CT.
Hi Sid, great info
Have you seen the OpenEHR REST API? You might want to check that out. I'm guessing you're going to like it. By the way, excellent channel. Please keep it up.
I disagree with your assessment of why FHIR is limited by the 80:20 rule. First, the 80:20 rule means that FHIR seeks to implement at least 80% of a given resource. 20% remains unique to a country or jurisdiction. This is because different countries have some unique requirements that are not the same as those in other countries and as such you can’t force them to adapt the same profiles - so FHIR is flexible. This also allows developers to build applications based the requirements of the profile they are given. Also as an app developer, you could build an app with as many blood pressure characteristics as you want using FHIR if your customer wants to do that - it’s all dependent on the profile you are given.
Main difference is having a base Reference Model that ensures that everyone at least works with the same base rules. Extension mechanism is very powerful, but can easily get out of hand fast
@@medblocks I can understand the desire to write an application once and forget about it. I think that it might be a little restrictive since you might not always be able to cover every thing a customer might need. Am not familiar with OpenEHR so I might be missing something. However, I doubt that it is possible that it would cover everything every one in the world would ever want to cover for each of the resources. Therefore the extensions of FHIR become really powerful.
@@medblocks This makes OpenEHR too inflexible to use in practice. For example, in our application, we need to include the patient's age when the measurement was taken with each data point. We are specifically not allowed to include the dates, and the patient birthdate is not allowed in the data. This was not anticipated in the FHIR standard and is not present in OpenEHR. When OpenEHR matures to the point FHIR has, it will take a lot of coordination to get this added, delaying the project by years. However, with FHIR, we can use the age-at-event extension (github.com/ncpi-fhir/ncpi-model-forge/blob/6656a2c6550a3000623cb43c3d9c6f1d06aef7d5/site_root/input/resources/extensions/StructureDefinition-age-at-event.json). Right now, this means that there are a lot of potential representations that application developers need to consider. However, as time goes on, the community will converge on a standard. The US Core Standards people will negotiate with the NDHM to create convergent implementation guides. Though I'd love to be proven wrong, OpenEHR is probably yet another incompatible standard, not the one unifying standard that will take care of everyone's use-cases. See xkcd.com/927/
@@medblocks While I agree with your disagreement to the point above, I disagree with your general argument. The lack of Ambiguitiy stems from the level of abstraction between the two - with OpenEHR being more abstract. Everything is more or less an observeation. Dealing with specifics mandated locally and deeper syntactic interoperability on a standardized level as opposed to delegating them the the implementer makes sense on the long term. You are right in that the standardazation work is excrutiatingly slow.
No. In fact, the whole of medical specialties will be in those 20%. One doctor's daily chores are another doctor's edge cases.
Hi iam very new to fhir my doubt may be silly please dnt mind, we are posting our patient details and it generates an id so we can get what ever we posted iam good upto there how does it help in real time to the providers and patients how they use this data... can we get data from another provider of patient who came from that hospital iam little bit confused iam imaging like get is like we get data from another providers if we can get how? post means we post our data to fhir server which can be accessed by others iam I crt
@@medblocks how smart fhir works? we created observation vitals resources they need to know our ids know to call get or post sorry for bothering you so much how smart fhir knows those
Thanks in a million. Great content. Grade: A++Thanks in a million. Great content. Grade: A++Thanks in a million. Great content. Grade: A++