HL7v3 vs. HL7 FHIR comparison
The following article is again my free translation of the comparison, and more precisely, indications of the shortcomings of HL7v3 and the merits of HL7 FHIR (Fast Healthcare Interoperability Resources). The article “ The HL7 Games: Catching FHIR ” was written by BC Holmes (that’s right, but since I’m not familiar with her personally, it wasn’t possible to ask what the name “BC” means), a person who doesn’t use abstract examples, but specifically knows about HL7v3, and from the point of view of the implementation of many of its domains and messages. Moreover, she was the manager of one of the HL7v3 development tools.
In this regard, the article is full of details, so if your experience in this area is small or, especially, if you are not familiar with v3 at all, then it will often be very difficult to understand what she is talking about. For example, if you have never used the RMIM modeling tool and further serialization in the XML schema, it will be difficult to understand why naming problems arise when the ActRelationships model class is called “componentOf2”, and in the XML schema it also has the “Component6” type . (As it is done, for example, in CMET COCT_RM360000UV01 - MedicationOrder Universal. Other similar examples can be found there, “subjectOf1” is of type “Subject4”, etc.)
I, of course, will not translate the entire article to BC Holmes, I urge you to carefully read it yourself. Below are only the extracts from each of the comments and what FHIR can offer to solve them. At the end of my article there will be one interesting “interestingness”. My comments, as last time, in square brackets.
So, let's begin.
')
At the very beginning, BC Holmes argues that no one should be surprised, at least for those who have participated in numerous HL7v3 implementations in Canada, that the v3 standard is almost universally considered to have failed. In general, I would argue, she writes, that the standard failed for the following reasons:
• HL7v3 models and messages are much more complex than any other XML-based messaging standard.
• This complexity cannot be eliminated by writing more intelligent and understandable documentation, since implementation guides must be compiled from many different sources, such as documentation of the UV [ universal ] implementation [ the v3 standard itself ], the Canadian implementation standard from Canada Health Infoway, and implementation standards and guidelines from specific jurisdictions or provinces.
• The HL7v3 standard lacks a utility model for creating extensions. Thus, the official process of “restricting” [ constrain ] a standard for the needs of a particular jurisdiction rarely achieves the required goals. Ultimately, all jurisdictions have come up with implementations, which are to some extent different from the published standard, in order to maintain their existing medical processes.
• The HL7v3 data types defined in the standard present a number of difficulties for implementing HL7v3 compatible systems. [ I wrote about data types in this article . ]
• Finally, terminology has proven to be a rather complex area.
We now consider these statements in more detail, Holmes writes, and consider the extent to which FHIR solves these problems.
Complexity
The fact that the HL7v3 standard is too complicated should now be accepted as a fait accompli. In this sense, Intelliware was the first Cassandra, who predicted this in 2007, after the implementation of one of our first POS applications. Since then, this echo has responded many times among other developers. So I am sure that anyone who has ever encountered the implementation of v3, does not doubt its complexity.
One of the ways to quantify this complexity in calculating the nesting levels of a typical v3 message, it usually has 5-10 times more XML nodes [ Interestingly, in the Russian Wiki the word node in the article about XML is not found once! ] than any other XML-based standards, such as Interactive Financial eXchange (IFX) or Amazon EC2 SOAP API. Someone may say that business processes in healthcare are much more complicated and semantically richer than in the financial field and, especially, in publishing. In my opinion, this is not the problem - I had the experience of upgrading the HL7v2-based system presented in XML [a message v2 can be represented not only with chopsticks and caps, but also in XML format ] by replacing it with HL7v3, and I saw an increase in complexity by an order of magnitude. So, most likely, this is a characteristic feature of the HL7v3. In any case, developers are faced with messages, the complexity level of which exceeds everything they could see before. [ I wonder what the developer will say, who saw only v3, and then switched to something else. Probably, everything else will be like two bytes on asphalt. ]
All trash
HL7v3 messages often contain a lot of unnecessary “junk”, the most striking examples of which are the structural attributes “moodCode” and “classCode”. In 99% of cases, these attributes have no meaning in the message. It is gratifying to see that in FHIR all such attributes were left out.
Naming issues
James Agnew once remarked that while HL7v3 was intended as a haven for medical informatists on message modeling [ See my article on What is HL7 ], it has become a hell for developers. In a sense, the modeling process has led to the emergence of unnecessary "junk", as mentioned above. A more serious problem is in the way naming entities are in message v3.
If you try to find some simple term, for example, “prescription” [ recipe ], then you can hardly find a message or its part with that name. You may find something similar, like the “activate prescription request,” but you will have to carefully study the naming of the entities in this message, after which you may find that the recipe is hidden under the name “combined medication request”.
[ The article provides examples, some of which I placed at the beginning of my article. On my own behalf, I can add that take CDA and think about why in some classes, for example, AssignedEntity, the addr attribute precedes telecom, while in other classes, for example, Organization, the order of the same attributes is reversed, i.e. first telecom, then addr. When serialized in XML, the order of the elements will matter and may cause an error. ]
Fortunately, the clarity of resource field designations is paramount in FHIR, and even simple and understandable things like “dob” are replaced with more international “birthDate”.
Nesting
Take v3 clinical document messages which should be used in approximately the same way as CDA documents [ It is not quite clear what this is about, in the standard several domains have a structure similar to CDA, for example, Clinical Decision Support, Medical Records and a separate Clinical Statement as an integral part of other models. ]. In HL7v3, the document is hidden deep inside the message, so an image or PDF is embedded in a construct that attempts to describe the structure of unstructured data. This construction, in turn, is embedded in another construction with meta-data on authorship, date and patient. This does not end the nesting, all this is enclosed in other envelopes, which are so called control act wrapper [ full name Trigger Event Control Act Wrapper ] and transport wrapper. Everything else, the message v3, as a rule, is in itself wrapped in a SOAP message. Just like a mystery, wrapped in mystery and placed inside the puzzle.
In contrast, one of the nice features of FHIR is the flat presentation of the message. Even in the most difficult cases, the data is not more than 10 levels of nesting, and most often in 5 levels from the root of the message. This flat structure also avoids duplication of data, while in HL7v3 it is possible to reproduce the data several times in different parts of the message, which is especially characteristic of the physician participating in the treatment process, as well as for disease data that can be repeated in prescriptions.
The various v3 wrappers were replaced by the current OAuth standard [ It would not be bad if someone familiar with this commented on the specifics of using OAuth ]. Even the problem with multiple data - the continuation pointer (give me the next 50 patients who meet the search criteria) - is implemented using the existing Atom standard.
Documentation
Availability of documentation was one of the HL7v3 headaches. If with other technologies, the problem is that there is not enough documentation, in the case of v3, everything is just the opposite, there is simply a mountain of documentation, often developed by various organizations, often inaccessible to developers due to paid access, etc.
One of the significant things that was done at FHIR is that they posted all the documentation in the public domain on the site . Probably due to the fact that the FHIR documentation is focused on implementation, it is very specific and full of details. [ Well, messaging and documents are so far written very superficially. If you need to make a complex request, do not fence it all in the url, messaging will fit much better. ]
Extensibility
In the general case, in the HL7v3 world, experts define some kind of interaction between medical systems and produce a description in the form of a Model Interchange Format (MIF) file. Developers take this file and create a message from it. [ In theory. In practice, tools to work with MIF files as on the fingers of one hand. ] Very often there is a need to transfer data that was not originally included in the message, and then the problems begin. [The problems also begin with the fact that if the XML schema changes, it is not possible to display these changes in the MIF, no automated tools are provided for this. What instantly makes the initial MIF not normative for a particular implementation. In particular, for the same reason, the CDA MIF is presented in the ballot edition, but not in the normative edition - because the CDA scheme has been changed. ]
Perhaps due to the initial commitment to the 80/20 rule, FHIR has a fairly good mechanism for creating extensions. Any resource can be expanded. Extensions have a simple key-value format. The value can be either a simple data type or a complex one due to nested extensions.
I can argue that extensions will be one of the most useful features in FHIR.
Data types
Work on the HL7v3 began before most modern standards, such as XML, came into being. Even though the HL7v3 message is in XML format, the HL7v3 does not exactly match the XML. Data types are one example of this. For example, in HL7v3, primitive data types ST (String) and BL (Boolean) are defined, which differ significantly from data types typical of XML, making them difficult to use with commercial development tools.
FHIR, taught by bitter experience, for primitive data types (boolean, string, date, uri, etc.) uses all the same as XML. More complex data types (Address, Coding, Quantity, HumanName, etc.) are based on the same primitive data. A side effect of this type of data alteration in the possibility of message validation and testing.
Terminology
Terminology is the presentation of certain concepts in coded form. Significant time to implement the honey system is spent on decisions about how to encode the concept. Should ICD-10 or SNIOMED CT be used to classify diseases? Do you use DIN or RxNorm for drug recording? In addition, to ensure compatibility, it is necessary to decide how the internal codes of the system correspond to external dictionaries [ with the same SNOMED CT ].
FHIR is not too far away in using terminology, although it avoids the use of certain kinds of codes in the message.
Sticks and caps
Until we see a sufficiently large solution based on FHIR, we can hardly say whether FHIR will be a better solution from the point of support for real compatibility than HL7 v2 . It may be that FHIR will simply become a tool that will replace HL7 v2 messages with a more modern REST / JSON counterpart. And even if that happens, I will still claim that FHIR is a better solution than HL7v2 or HL7v3.
Conclusion
Even in spite of its newness, FHIR seems to be a more attractive alternative to HL7v3, especially since it is built on modern standards, like REST, JSON, OAuth and even, oddly enough, Atom [ Who knows Atom well, explain why to be weird? ]. Therefore, for organizations we recommend:
• Assess the applicability of FHIR in your environment - even a small proof-of-concept project can help you understand how the standard fits your needs;
• It is better to use FHIR, than to invent your own API;
• Avoid using HL7v3 in new projects unless there are objective reasons (existing code, access points on v3);
• Consider replacing the HL7v2 interfaces with FHIR.
[ On this article BC Holmes ends, then the continuation of my article. ]
Well, now the promised "interesting." There is a comment by Lloyd McKenzie on the observations of BC Holmes. Who does not know who Lloyd is, this is one of the active creators of the HL7v3 standard, in particular, RMIM Designer, his brainchild, as well as one of the three firefighters (FHIR-man) who file FHIR standard files before its actual use. All the more interesting to hear what he thinks. I will try to translate as accurately as possible to the original, because his answer is on one of the closed Canada Health Infoway forums and there’s no access to the outside. To make it clearer, Lloyd is in Canada, so some of his comments relate to the implementation of v3 in Canada.
“I think - [ Lloyd writes ] - there are various ways to classify the“ failure ”of a standard. It is absolutely proved that it is possible to implement v3 (with an adequate level of time and investment) by achieving at least some degree of compatibility. From this point of view, the standard can be considered successful.
However, there are other areas where it is difficult to say about their success:
• Market support turned out to be more than limited than originally expected. In addition to CDA, v3 was largely limited to large, state-funded projects with serious funding, a lot of time and influence.
• Compatibility is highly problematic. Canada, the UK and the Netherlands have implemented a v3-based drug formulation, but significant message transformations will be required to achieve compatibility [ between these implementations ]. Somewhat less similar interoperability problems exist between provinces in Canada. Some of them are caused by different solutions, but the fact that the introduction of each new element violates compatibility only complicates the problem.
• From the point of view of developers, it is quite difficult to find those who are delighted with the ease, speed and cost of implementing compatibility with HL7v3 (or CDA). Among those who experience the joy of this, the most commonly encountered are v3 counselors. [ In particular, like me - writes Lloyd. ]
I actually like v3 in terms of modeling it. It was a very powerful modeling tool. But I came to the conclusion that the methodology and standards that go out of it do not bring results comparable to the investment spent.
I'm not saying that FHIR will be a panacea, it is still in development. But he is already able to solve some of the problems with v3, such as learning complexity, overly complex messages, differences between messages from different developers, and the lack of an extension mechanism. And more importantly, he is gaining considerable power among developers in an environment where no one can say “yes,” that is, where different developers look at examples and say, “but what can I do.” This is not at all what happened with v3 and in rare cases happened with CDA.
Given the investments already made in v3 in Canada and the fact that FHIR is not yet a normative, it would be premature to talk about the migration of existing implementations, but it probably makes sense to start exploring the possibility of using FHIR for new implementations and decide whether it is suitable in the case where or if suddenly we decide to go for it. (I think FHIR is the only way to ever see the significant compatibility of systems between different jurisdictions.)
At the end [ Lloyd writes ]:
• I created numerous v3 models and implementation guides, trained v3 around the world, and participated in several v3 projects. I was getting quite well as a v3 consultant.
• Now I spend a lot of my time, and my employer's time, working on FHIR on a voluntary basis. [ Further, Lloyd complains that in financial terms this brings little benefit. ] Those who will implement FHIR will not need such serious support as in the case of v3. On the other hand, there will still be quite a lot of consulting work on creating sensible developer guides, building consensus among the interested parties (compatibility, after all, in that the interested parties agree on what part of the information can be transmitted), glossaries and so on. ”
=====
Actually, this can be completed. Perhaps someone was expecting a comparison of the two standards for items under a microscope. But today FHIR raises more questions than answers; there are no real, not toy, realizations yet, so a comparison is rather difficult to make. (There is no one here from IBS, as far as I understand, to tell you how much Think! EHR supports FHIR, as it is declared on the vendor page.)
In this regard, the article is full of details, so if your experience in this area is small or, especially, if you are not familiar with v3 at all, then it will often be very difficult to understand what she is talking about. For example, if you have never used the RMIM modeling tool and further serialization in the XML schema, it will be difficult to understand why naming problems arise when the ActRelationships model class is called “componentOf2”, and in the XML schema it also has the “Component6” type . (As it is done, for example, in CMET COCT_RM360000UV01 - MedicationOrder Universal. Other similar examples can be found there, “subjectOf1” is of type “Subject4”, etc.)
I, of course, will not translate the entire article to BC Holmes, I urge you to carefully read it yourself. Below are only the extracts from each of the comments and what FHIR can offer to solve them. At the end of my article there will be one interesting “interestingness”. My comments, as last time, in square brackets.
So, let's begin.
')
At the very beginning, BC Holmes argues that no one should be surprised, at least for those who have participated in numerous HL7v3 implementations in Canada, that the v3 standard is almost universally considered to have failed. In general, I would argue, she writes, that the standard failed for the following reasons:
• HL7v3 models and messages are much more complex than any other XML-based messaging standard.
• This complexity cannot be eliminated by writing more intelligent and understandable documentation, since implementation guides must be compiled from many different sources, such as documentation of the UV [ universal ] implementation [ the v3 standard itself ], the Canadian implementation standard from Canada Health Infoway, and implementation standards and guidelines from specific jurisdictions or provinces.
• The HL7v3 standard lacks a utility model for creating extensions. Thus, the official process of “restricting” [ constrain ] a standard for the needs of a particular jurisdiction rarely achieves the required goals. Ultimately, all jurisdictions have come up with implementations, which are to some extent different from the published standard, in order to maintain their existing medical processes.
• The HL7v3 data types defined in the standard present a number of difficulties for implementing HL7v3 compatible systems. [ I wrote about data types in this article . ]
• Finally, terminology has proven to be a rather complex area.
We now consider these statements in more detail, Holmes writes, and consider the extent to which FHIR solves these problems.
Complexity
The fact that the HL7v3 standard is too complicated should now be accepted as a fait accompli. In this sense, Intelliware was the first Cassandra, who predicted this in 2007, after the implementation of one of our first POS applications. Since then, this echo has responded many times among other developers. So I am sure that anyone who has ever encountered the implementation of v3, does not doubt its complexity.
One of the ways to quantify this complexity in calculating the nesting levels of a typical v3 message, it usually has 5-10 times more XML nodes [ Interestingly, in the Russian Wiki the word node in the article about XML is not found once! ] than any other XML-based standards, such as Interactive Financial eXchange (IFX) or Amazon EC2 SOAP API. Someone may say that business processes in healthcare are much more complicated and semantically richer than in the financial field and, especially, in publishing. In my opinion, this is not the problem - I had the experience of upgrading the HL7v2-based system presented in XML [a message v2 can be represented not only with chopsticks and caps, but also in XML format ] by replacing it with HL7v3, and I saw an increase in complexity by an order of magnitude. So, most likely, this is a characteristic feature of the HL7v3. In any case, developers are faced with messages, the complexity level of which exceeds everything they could see before. [ I wonder what the developer will say, who saw only v3, and then switched to something else. Probably, everything else will be like two bytes on asphalt. ]
All trash
HL7v3 messages often contain a lot of unnecessary “junk”, the most striking examples of which are the structural attributes “moodCode” and “classCode”. In 99% of cases, these attributes have no meaning in the message. It is gratifying to see that in FHIR all such attributes were left out.
Naming issues
James Agnew once remarked that while HL7v3 was intended as a haven for medical informatists on message modeling [ See my article on What is HL7 ], it has become a hell for developers. In a sense, the modeling process has led to the emergence of unnecessary "junk", as mentioned above. A more serious problem is in the way naming entities are in message v3.
If you try to find some simple term, for example, “prescription” [ recipe ], then you can hardly find a message or its part with that name. You may find something similar, like the “activate prescription request,” but you will have to carefully study the naming of the entities in this message, after which you may find that the recipe is hidden under the name “combined medication request”.
[ The article provides examples, some of which I placed at the beginning of my article. On my own behalf, I can add that take CDA and think about why in some classes, for example, AssignedEntity, the addr attribute precedes telecom, while in other classes, for example, Organization, the order of the same attributes is reversed, i.e. first telecom, then addr. When serialized in XML, the order of the elements will matter and may cause an error. ]
Fortunately, the clarity of resource field designations is paramount in FHIR, and even simple and understandable things like “dob” are replaced with more international “birthDate”.
Nesting
Take v3 clinical document messages which should be used in approximately the same way as CDA documents [ It is not quite clear what this is about, in the standard several domains have a structure similar to CDA, for example, Clinical Decision Support, Medical Records and a separate Clinical Statement as an integral part of other models. ]. In HL7v3, the document is hidden deep inside the message, so an image or PDF is embedded in a construct that attempts to describe the structure of unstructured data. This construction, in turn, is embedded in another construction with meta-data on authorship, date and patient. This does not end the nesting, all this is enclosed in other envelopes, which are so called control act wrapper [ full name Trigger Event Control Act Wrapper ] and transport wrapper. Everything else, the message v3, as a rule, is in itself wrapped in a SOAP message. Just like a mystery, wrapped in mystery and placed inside the puzzle.
In contrast, one of the nice features of FHIR is the flat presentation of the message. Even in the most difficult cases, the data is not more than 10 levels of nesting, and most often in 5 levels from the root of the message. This flat structure also avoids duplication of data, while in HL7v3 it is possible to reproduce the data several times in different parts of the message, which is especially characteristic of the physician participating in the treatment process, as well as for disease data that can be repeated in prescriptions.
The various v3 wrappers were replaced by the current OAuth standard [ It would not be bad if someone familiar with this commented on the specifics of using OAuth ]. Even the problem with multiple data - the continuation pointer (give me the next 50 patients who meet the search criteria) - is implemented using the existing Atom standard.
Documentation
Availability of documentation was one of the HL7v3 headaches. If with other technologies, the problem is that there is not enough documentation, in the case of v3, everything is just the opposite, there is simply a mountain of documentation, often developed by various organizations, often inaccessible to developers due to paid access, etc.
One of the significant things that was done at FHIR is that they posted all the documentation in the public domain on the site . Probably due to the fact that the FHIR documentation is focused on implementation, it is very specific and full of details. [ Well, messaging and documents are so far written very superficially. If you need to make a complex request, do not fence it all in the url, messaging will fit much better. ]
Extensibility
In the general case, in the HL7v3 world, experts define some kind of interaction between medical systems and produce a description in the form of a Model Interchange Format (MIF) file. Developers take this file and create a message from it. [ In theory. In practice, tools to work with MIF files as on the fingers of one hand. ] Very often there is a need to transfer data that was not originally included in the message, and then the problems begin. [The problems also begin with the fact that if the XML schema changes, it is not possible to display these changes in the MIF, no automated tools are provided for this. What instantly makes the initial MIF not normative for a particular implementation. In particular, for the same reason, the CDA MIF is presented in the ballot edition, but not in the normative edition - because the CDA scheme has been changed. ]
Perhaps due to the initial commitment to the 80/20 rule, FHIR has a fairly good mechanism for creating extensions. Any resource can be expanded. Extensions have a simple key-value format. The value can be either a simple data type or a complex one due to nested extensions.
I can argue that extensions will be one of the most useful features in FHIR.
Data types
Work on the HL7v3 began before most modern standards, such as XML, came into being. Even though the HL7v3 message is in XML format, the HL7v3 does not exactly match the XML. Data types are one example of this. For example, in HL7v3, primitive data types ST (String) and BL (Boolean) are defined, which differ significantly from data types typical of XML, making them difficult to use with commercial development tools.
FHIR, taught by bitter experience, for primitive data types (boolean, string, date, uri, etc.) uses all the same as XML. More complex data types (Address, Coding, Quantity, HumanName, etc.) are based on the same primitive data. A side effect of this type of data alteration in the possibility of message validation and testing.
Terminology
Terminology is the presentation of certain concepts in coded form. Significant time to implement the honey system is spent on decisions about how to encode the concept. Should ICD-10 or SNIOMED CT be used to classify diseases? Do you use DIN or RxNorm for drug recording? In addition, to ensure compatibility, it is necessary to decide how the internal codes of the system correspond to external dictionaries [ with the same SNOMED CT ].
FHIR is not too far away in using terminology, although it avoids the use of certain kinds of codes in the message.
Sticks and caps
Until we see a sufficiently large solution based on FHIR, we can hardly say whether FHIR will be a better solution from the point of support for real compatibility than HL7 v2 . It may be that FHIR will simply become a tool that will replace HL7 v2 messages with a more modern REST / JSON counterpart. And even if that happens, I will still claim that FHIR is a better solution than HL7v2 or HL7v3.
Conclusion
Even in spite of its newness, FHIR seems to be a more attractive alternative to HL7v3, especially since it is built on modern standards, like REST, JSON, OAuth and even, oddly enough, Atom [ Who knows Atom well, explain why to be weird? ]. Therefore, for organizations we recommend:
• Assess the applicability of FHIR in your environment - even a small proof-of-concept project can help you understand how the standard fits your needs;
• It is better to use FHIR, than to invent your own API;
• Avoid using HL7v3 in new projects unless there are objective reasons (existing code, access points on v3);
• Consider replacing the HL7v2 interfaces with FHIR.
[ On this article BC Holmes ends, then the continuation of my article. ]
Well, now the promised "interesting." There is a comment by Lloyd McKenzie on the observations of BC Holmes. Who does not know who Lloyd is, this is one of the active creators of the HL7v3 standard, in particular, RMIM Designer, his brainchild, as well as one of the three firefighters (FHIR-man) who file FHIR standard files before its actual use. All the more interesting to hear what he thinks. I will try to translate as accurately as possible to the original, because his answer is on one of the closed Canada Health Infoway forums and there’s no access to the outside. To make it clearer, Lloyd is in Canada, so some of his comments relate to the implementation of v3 in Canada.
“I think - [ Lloyd writes ] - there are various ways to classify the“ failure ”of a standard. It is absolutely proved that it is possible to implement v3 (with an adequate level of time and investment) by achieving at least some degree of compatibility. From this point of view, the standard can be considered successful.
However, there are other areas where it is difficult to say about their success:
• Market support turned out to be more than limited than originally expected. In addition to CDA, v3 was largely limited to large, state-funded projects with serious funding, a lot of time and influence.
• Compatibility is highly problematic. Canada, the UK and the Netherlands have implemented a v3-based drug formulation, but significant message transformations will be required to achieve compatibility [ between these implementations ]. Somewhat less similar interoperability problems exist between provinces in Canada. Some of them are caused by different solutions, but the fact that the introduction of each new element violates compatibility only complicates the problem.
• From the point of view of developers, it is quite difficult to find those who are delighted with the ease, speed and cost of implementing compatibility with HL7v3 (or CDA). Among those who experience the joy of this, the most commonly encountered are v3 counselors. [ In particular, like me - writes Lloyd. ]
I actually like v3 in terms of modeling it. It was a very powerful modeling tool. But I came to the conclusion that the methodology and standards that go out of it do not bring results comparable to the investment spent.
I'm not saying that FHIR will be a panacea, it is still in development. But he is already able to solve some of the problems with v3, such as learning complexity, overly complex messages, differences between messages from different developers, and the lack of an extension mechanism. And more importantly, he is gaining considerable power among developers in an environment where no one can say “yes,” that is, where different developers look at examples and say, “but what can I do.” This is not at all what happened with v3 and in rare cases happened with CDA.
Given the investments already made in v3 in Canada and the fact that FHIR is not yet a normative, it would be premature to talk about the migration of existing implementations, but it probably makes sense to start exploring the possibility of using FHIR for new implementations and decide whether it is suitable in the case where or if suddenly we decide to go for it. (I think FHIR is the only way to ever see the significant compatibility of systems between different jurisdictions.)
At the end [ Lloyd writes ]:
• I created numerous v3 models and implementation guides, trained v3 around the world, and participated in several v3 projects. I was getting quite well as a v3 consultant.
• Now I spend a lot of my time, and my employer's time, working on FHIR on a voluntary basis. [ Further, Lloyd complains that in financial terms this brings little benefit. ] Those who will implement FHIR will not need such serious support as in the case of v3. On the other hand, there will still be quite a lot of consulting work on creating sensible developer guides, building consensus among the interested parties (compatibility, after all, in that the interested parties agree on what part of the information can be transmitted), glossaries and so on. ”
=====
Actually, this can be completed. Perhaps someone was expecting a comparison of the two standards for items under a microscope. But today FHIR raises more questions than answers; there are no real, not toy, realizations yet, so a comparison is rather difficult to make. (There is no one here from IBS, as far as I understand, to tell you how much Think! EHR supports FHIR, as it is declared on the vendor page.)
Source: https://habr.com/ru/post/258113/
All Articles