Comparison of HL7v3 and HL7 FHIR
The following article is again my free translation comparison, or rather, pointing out the disadvantages of HL7v3 and the advantages of HL7 FHIR (Fast Healthcare Interoperability Resources). The article “ The HL7 Games: Catching FHIR ” was written by BC Holmes (that’s the way, but since I don’t know her personally, there was no way to ask what the name “BC” means), a person who is not on abstract examples, but even specifically knows about HL7v3, and from the point of view of implementing many of its domains and messages. Moreover, she was the manager of one of the development tools HL7v3.
In this regard, the article is replete with details, so if your experience in this area is small or, moreover, if you are not familiar with v3 at all, then it will often be very difficult to understand what it says. For example, if you have never used RMIM modeling tools and further serialization in XML schemas, it will be difficult to understand why naming problems occur when the class is called “componentOf2” in the ActRelationships model and it is of the “Component6” type in the XML schema . (As is done, for example, in CMET COCT_RM360000UV01 - MedicationOrder Universal. Other similar examples can be found there, “subjectOf1” has the type “Subject4”, etc.)
Naturally, I will not translate the entire BC Holmes article; I urge you to read it yourself carefully. Only extracts from each of the comments will be given below and what the FHIR has to offer to solve them. At the end of my article there will be one interesting “interestingness”. My comments, like last time, are in square brackets.
So, let's begin.
At the very beginning, BC Holmes argues that it should not come as a surprise to anyone, at least not to anyone who has participated in numerous implementations of HL7v3 in Canada, that the v3 standard is almost universally considered failed. In the general case, I would argue, she writes, that the standard failed for the following reasons:
• HL7v3 models and messages are much more complex than in any other XML-based messaging standard.
• This complexity cannot be eliminated by writing more sensible and understandable documentation, because Implementation guides should be glued from a wide variety of sources, such as UV [ universal ] implementation documentation [ v3 standard itself ], Canadian implementation standard from Canada Health Infoway, and implementation standards and guidelines from specific jurisdictions or provinces.
• The HL7v3 standard lacks a useful model for creating extensions. So, the official process of "limitation" [ constrain] a standard for the needs of a particular jurisdiction rarely achieves the required objectives. Ultimately, all jurisdictions came to implementations that, to one degree or another, differed from the published standard, in order to maintain their existing medical processes.
• The data types defined in the HL7v3 standard present a number of difficulties for implementing HL7v3 compatible systems. [ I wrote about data types in this article . ]
• And the last, terminology turned out to be a rather complicated area.
Now consider these statements in more detail, writes Holmes, and consider the extent to which FHIR solves these problems.
Complexity
That the HL7v3 standard is too complex should be accepted as a fait accompli at the moment. Intelliware in this sense was the first Cassandra to prophesy about this back in 2007, after implementing one of our first POS applications. Since then, this echo has responded many times among other developers. So I'm sure that anyone who has ever encountered the implementation of v3 has no doubt about its complexity.
One of the ways to quantify this complexity in calculating the nesting levels of a typical v3 message is, as a rule, it has 5-10 times more XML nodes [ It is interesting that in the Russian Wiki the word node in the article about XML never appears!] than any other XML-based standards, such as the Interactive Financial eXchange (IFX) or Amazon EC2 SOAP API. Someone may say that business processes in healthcare are much more complex and semantically richer than in the financial field and, especially, in book publishing. In my opinion, this is not the problem - I had experience upgrading an HL7v2-based system presented in XML [a v2 message can be represented not only with sticks and caps, but also in XML format ] replacing this with HL7v3, and I saw an increase in complexity by an order of magnitude. So, most likely, this is a characteristic feature of HL7v3. In any case, developers are faced with messages whose level of complexity exceeds everything they could see before. [It’s interesting, but what will the developer say, who saw only v3, and then switched to something else. Probably everything else will be like two bytes on the asphalt. ]
Any trash
HL7v3 messages often contain a lot of unnecessary “trash”, the most striking example of which are the structural attributes “moodCode” and “classCode”. In 99% of cases, these attributes do not make any sense in the message. It is gratifying to see that in FHIR all such attributes were left overboard.
Naming problems
James Agnew once noticed that while HL7v3 was conceived as a paradise for medical informatists on message modeling [ See my article What is HL7], he became a living hell for developers. In a sense, the modeling process led to the appearance of unnecessary “junk”, as mentioned above. A more serious problem is the way naming entities in the v3 message.
If you try to find some simple term, for example, “prescription” [ recipe ], then you are unlikely to find a message or part of it with that name. You may find something similar, such as “activate prescription request”, but you will have to carefully study the naming of entities in this message, after which you may find that the recipe is hiding 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 the CDA and think 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 lead to an error. ]
Fortunately, clarity of resource field designations is of primary importance in FHIR, and even simple and understandable things like “dob” are replaced with more international “birthDate”.
Nesting
Take v3 clinical document messages that should be used in much the same way as CDA documents [It’s not entirely clear what this is about, in the standard there are several domains having a structure similar to CDA, for example, Clinical Decision Support, Medical Records and separately Clinical Statement as an integral part of other models. ]. In HL7v3, a 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 design, in turn, is embedded in another design with meta-data about authorship, date and patient. Nesting does not end there, all this is embedded in other envelopes, which are called control act wrapper [ full name Trigger Event Control Act Wrapper] and transport wrapper. In addition, a v3 message is usually wrapped in a SOAP message by itself. Just like a riddle wrapped in mystery and placed inside a 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 no more than 10 levels of nesting, and most often at 5 levels from the root of the message. Such a flat structure also avoids duplication of data, while in HL7v3 it is possible to reproduce data several times in different parts of the message, which is especially true for the doctor involved in the treatment process, as well as for disease data that can be repeated in prescriptions.
Various wrappers for v3 have been replaced by the modern OAuth standard [It would not be bad if someone familiar with this would comment on the features of using OAuth ]. Even the problem with multiple data - the continuation pointer (give me the next 50 patients that match the search criteria) - is implemented using the existing Atom standard.
Documentation
The availability of documentation was one of the headaches of HL7v3. If with other technologies the problem is that the documentation is not enough, then in the case of v3 it is just the opposite, here is just a mountain of documentation, often developed by various organizations, often inaccessible to developers due to paid access, etc.
One of the significant things that FHIR did was to post all the documentation in the public domain on the website.. Probably because the FHIR documentation is aimed at implementation, it is very specific and abounds with details. [ Well, messaging and documents have so far been written very superficially. If you need to make a complex request, do not block it all in the url, messaging will do much better. ]
Extensibility
In general, in the HL7v3 world, experts determine 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 for working with MIF files as on the fingers of one hand. ] Very often there is a need to transfer data that was not originally laid down in the message, and here the problems begin. [The problems also begin with the fact that when changing the XML schema, there is no way to display these changes in MIF, nor are there any automated tools for this. Which 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 is missing in the normative edition - because the CDA scheme has been changed. ]
Perhaps because of the initial commitment to the 80/20 rule, FHIR has a pretty 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 complex due to nested extensions.
I bet that extensions will be one of the most useful features in FHIR.
Data types
Work on HL7v3 began before most modern standards, such as XML, came into being. Even though the HL7v3 message is in XML format, HL7v3 never exactly matched 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 the data types specific to 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 everything the same as XML. More complex data types (Address, Coding, Quantity, HumanName, etc.) are based on the same primitive data. A side effect of such alteration of data types is the possibility of message validation and testing.
Terminology
Terminology is a representation of certain concepts in coded form. Significant time for the implementation of the honey system is spent on decisions on how to code concepts. Should ICD-10 or SNIOMED CT be used to classify diseases? And to record drugs use DIN or RxNorm? In addition, to ensure compatibility, it is necessary to decide how the internal codes of the system relate to external dictionaries [with the same SNOMED CT ].
FHIR has not gone too far in using terminology, although it avoids the use of certain types of codes in a message.
Sticks and lids
Until we see a sufficiently large FHIR-based solution, we are unlikely to say whether FHIR will be a better solution from the point of supporting real compatibility than HL7 v2 . It may happen 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’ll still state that FHIR is a better solution than HL7v2 or HL7v3.
Conclusion
Even despite its novelty, FHIR seems to be a more attractive alternative to HL7v3, especially since it is built on modern standards, such as REST, JSON, OAuth, and even, oddly enough, Atom [ Who is familiar with Atom, explain why this should 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 is suitable for your needs;
• Better to use FHIR than invent your own API;
• Avoid using HL7v3 in new projects if there are no objective reasons (existing code, access points on v3);
• Consider replacing HL7v2 interfaces with FHIR.
[This concludes the article by BC Holmes, followed by the continuation of my article. ]
Well, now the promised "interesting". There is a comment by Lloyd McKenzie on BC Holmes's comments. Who does not know who Lloyd is, he is one of the active creators of the HL7v3 standard, in particular, RMIM Designer is his brainchild, as well as one of three firefighters (FHIR-man) who file up the FHIR standard before its actual use. It’s all the more interesting to hear what he thinks. I will try to translate as accurately as possible to the original, because his answer to one of the closed Canada Health Infoway forums and access from there, it seems, is not. To make it clearer, Lloyd is in Canada, so part of his comments relate to the implementation of v3 in Canada.
“I think - [ writes Lloyd] - there are different ways to classify a “failure” of a standard. It has been precisely proven that it is possible to implement v3 (with the proper 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 assert their success:
• Market support was 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 very problematic. Canada, the United Kingdom, and the Netherlands have implemented v3-based drug formulations, but significant message conversions will be required to achieve compatibility [between these implementations ]. To a somewhat lesser extent, similar interaction problems exist between provinces in Canada. Some of them are caused by various 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 rather difficult to find those who are enthusiastic about the ease, speed and cost of implementing compatibility with HL7v3 (or CDA). Among those who enjoy this, v3 consultants are most often found. [ In particular, people like me, Lloyd writes. ]
I actually like v3 in terms of modeling it. The result is a very powerful modeling tool. But I came to the conclusion that the methodology and standards that come out of it do not bring a result comparable to the investment spent.
I am not saying that FHIR will be a panacea; it is still in development. But he is already able to solve some problems arising with v3, such as the complexity of training, overly complex messages, the differences between messages from different developers and the lack of an extension mechanism. And more importantly, it is gaining considerable strength among developers in an environment where no one can say for sure “so be it”, where different developers look at examples and say, “well, I can do that.” This is not at all what happened with v3 and in rare cases it happened with CDA.
Given the investments already made in v3 in Canada and the fact that FHIR is not yet 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 when or if suddenly we decide to switch to it. (I think FHIR is the only opportunity to ever see significant system compatibility between different jurisdictions.)
In conclusion [ Lloyd writes ]:
• I created numerous v3 models and implementation guides, trained v3 around the world and participated in several v3 projects. I was getting pretty good as a v3 consultant.
• Now I spend a lot of my time and that of my employer, working on FHIR on a voluntary basis. [ Further, Lloyd laments that in financial terms this is of little use. ] 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 a lot of consulting work on creating sensible developer guides, reaching consensus among interested parties (compatibility, in the end, is that interested parties agree on what part of the information can be transmitted), glossaries of terms, and so on. ”
=====
Actually, this can be completed. Perhaps someone was expecting a comparison of the two standards by points, under a microscope. But today, FHIR raises more questions than answers; there are no real, but not toy realizations, so comparing it is quite difficult. (There is no one from IBS, as I understand it, to tell you the extent to which Think! EHR supports FHIR, as declared on the vendor’s page.)
In this regard, the article is replete with details, so if your experience in this area is small or, moreover, if you are not familiar with v3 at all, then it will often be very difficult to understand what it says. For example, if you have never used RMIM modeling tools and further serialization in XML schemas, it will be difficult to understand why naming problems occur when the class is called “componentOf2” in the ActRelationships model and it is of the “Component6” type in the XML schema . (As is done, for example, in CMET COCT_RM360000UV01 - MedicationOrder Universal. Other similar examples can be found there, “subjectOf1” has the type “Subject4”, etc.)
Naturally, I will not translate the entire BC Holmes article; I urge you to read it yourself carefully. Only extracts from each of the comments will be given below and what the FHIR has to offer to solve them. At the end of my article there will be one interesting “interestingness”. My comments, like last time, are in square brackets.
So, let's begin.
At the very beginning, BC Holmes argues that it should not come as a surprise to anyone, at least not to anyone who has participated in numerous implementations of HL7v3 in Canada, that the v3 standard is almost universally considered failed. In the general case, I would argue, she writes, that the standard failed for the following reasons:
• HL7v3 models and messages are much more complex than in any other XML-based messaging standard.
• This complexity cannot be eliminated by writing more sensible and understandable documentation, because Implementation guides should be glued from a wide variety of sources, such as UV [ universal ] implementation documentation [ v3 standard itself ], Canadian implementation standard from Canada Health Infoway, and implementation standards and guidelines from specific jurisdictions or provinces.
• The HL7v3 standard lacks a useful model for creating extensions. So, the official process of "limitation" [ constrain] a standard for the needs of a particular jurisdiction rarely achieves the required objectives. Ultimately, all jurisdictions came to implementations that, to one degree or another, differed from the published standard, in order to maintain their existing medical processes.
• The data types defined in the HL7v3 standard present a number of difficulties for implementing HL7v3 compatible systems. [ I wrote about data types in this article . ]
• And the last, terminology turned out to be a rather complicated area.
Now consider these statements in more detail, writes Holmes, and consider the extent to which FHIR solves these problems.
Complexity
That the HL7v3 standard is too complex should be accepted as a fait accompli at the moment. Intelliware in this sense was the first Cassandra to prophesy about this back in 2007, after implementing one of our first POS applications. Since then, this echo has responded many times among other developers. So I'm sure that anyone who has ever encountered the implementation of v3 has no doubt about its complexity.
One of the ways to quantify this complexity in calculating the nesting levels of a typical v3 message is, as a rule, it has 5-10 times more XML nodes [ It is interesting that in the Russian Wiki the word node in the article about XML never appears!] than any other XML-based standards, such as the Interactive Financial eXchange (IFX) or Amazon EC2 SOAP API. Someone may say that business processes in healthcare are much more complex and semantically richer than in the financial field and, especially, in book publishing. In my opinion, this is not the problem - I had experience upgrading an HL7v2-based system presented in XML [a v2 message can be represented not only with sticks and caps, but also in XML format ] replacing this with HL7v3, and I saw an increase in complexity by an order of magnitude. So, most likely, this is a characteristic feature of HL7v3. In any case, developers are faced with messages whose level of complexity exceeds everything they could see before. [It’s interesting, but what will the developer say, who saw only v3, and then switched to something else. Probably everything else will be like two bytes on the asphalt. ]
Any trash
HL7v3 messages often contain a lot of unnecessary “trash”, the most striking example of which are the structural attributes “moodCode” and “classCode”. In 99% of cases, these attributes do not make any sense in the message. It is gratifying to see that in FHIR all such attributes were left overboard.
Naming problems
James Agnew once noticed that while HL7v3 was conceived as a paradise for medical informatists on message modeling [ See my article What is HL7], he became a living hell for developers. In a sense, the modeling process led to the appearance of unnecessary “junk”, as mentioned above. A more serious problem is the way naming entities in the v3 message.
If you try to find some simple term, for example, “prescription” [ recipe ], then you are unlikely to find a message or part of it with that name. You may find something similar, such as “activate prescription request”, but you will have to carefully study the naming of entities in this message, after which you may find that the recipe is hiding 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 the CDA and think 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 lead to an error. ]
Fortunately, clarity of resource field designations is of primary importance in FHIR, and even simple and understandable things like “dob” are replaced with more international “birthDate”.
Nesting
Take v3 clinical document messages that should be used in much the same way as CDA documents [It’s not entirely clear what this is about, in the standard there are several domains having a structure similar to CDA, for example, Clinical Decision Support, Medical Records and separately Clinical Statement as an integral part of other models. ]. In HL7v3, a 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 design, in turn, is embedded in another design with meta-data about authorship, date and patient. Nesting does not end there, all this is embedded in other envelopes, which are called control act wrapper [ full name Trigger Event Control Act Wrapper] and transport wrapper. In addition, a v3 message is usually wrapped in a SOAP message by itself. Just like a riddle wrapped in mystery and placed inside a 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 no more than 10 levels of nesting, and most often at 5 levels from the root of the message. Such a flat structure also avoids duplication of data, while in HL7v3 it is possible to reproduce data several times in different parts of the message, which is especially true for the doctor involved in the treatment process, as well as for disease data that can be repeated in prescriptions.
Various wrappers for v3 have been replaced by the modern OAuth standard [It would not be bad if someone familiar with this would comment on the features of using OAuth ]. Even the problem with multiple data - the continuation pointer (give me the next 50 patients that match the search criteria) - is implemented using the existing Atom standard.
Documentation
The availability of documentation was one of the headaches of HL7v3. If with other technologies the problem is that the documentation is not enough, then in the case of v3 it is just the opposite, here is just a mountain of documentation, often developed by various organizations, often inaccessible to developers due to paid access, etc.
One of the significant things that FHIR did was to post all the documentation in the public domain on the website.. Probably because the FHIR documentation is aimed at implementation, it is very specific and abounds with details. [ Well, messaging and documents have so far been written very superficially. If you need to make a complex request, do not block it all in the url, messaging will do much better. ]
Extensibility
In general, in the HL7v3 world, experts determine 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 for working with MIF files as on the fingers of one hand. ] Very often there is a need to transfer data that was not originally laid down in the message, and here the problems begin. [The problems also begin with the fact that when changing the XML schema, there is no way to display these changes in MIF, nor are there any automated tools for this. Which 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 is missing in the normative edition - because the CDA scheme has been changed. ]
Perhaps because of the initial commitment to the 80/20 rule, FHIR has a pretty 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 complex due to nested extensions.
I bet that extensions will be one of the most useful features in FHIR.
Data types
Work on HL7v3 began before most modern standards, such as XML, came into being. Even though the HL7v3 message is in XML format, HL7v3 never exactly matched 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 the data types specific to 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 everything the same as XML. More complex data types (Address, Coding, Quantity, HumanName, etc.) are based on the same primitive data. A side effect of such alteration of data types is the possibility of message validation and testing.
Terminology
Terminology is a representation of certain concepts in coded form. Significant time for the implementation of the honey system is spent on decisions on how to code concepts. Should ICD-10 or SNIOMED CT be used to classify diseases? And to record drugs use DIN or RxNorm? In addition, to ensure compatibility, it is necessary to decide how the internal codes of the system relate to external dictionaries [with the same SNOMED CT ].
FHIR has not gone too far in using terminology, although it avoids the use of certain types of codes in a message.
Sticks and lids
Until we see a sufficiently large FHIR-based solution, we are unlikely to say whether FHIR will be a better solution from the point of supporting real compatibility than HL7 v2 . It may happen 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’ll still state that FHIR is a better solution than HL7v2 or HL7v3.
Conclusion
Even despite its novelty, FHIR seems to be a more attractive alternative to HL7v3, especially since it is built on modern standards, such as REST, JSON, OAuth, and even, oddly enough, Atom [ Who is familiar with Atom, explain why this should 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 is suitable for your needs;
• Better to use FHIR than invent your own API;
• Avoid using HL7v3 in new projects if there are no objective reasons (existing code, access points on v3);
• Consider replacing HL7v2 interfaces with FHIR.
[This concludes the article by BC Holmes, followed by the continuation of my article. ]
Well, now the promised "interesting". There is a comment by Lloyd McKenzie on BC Holmes's comments. Who does not know who Lloyd is, he is one of the active creators of the HL7v3 standard, in particular, RMIM Designer is his brainchild, as well as one of three firefighters (FHIR-man) who file up the FHIR standard before its actual use. It’s all the more interesting to hear what he thinks. I will try to translate as accurately as possible to the original, because his answer to one of the closed Canada Health Infoway forums and access from there, it seems, is not. To make it clearer, Lloyd is in Canada, so part of his comments relate to the implementation of v3 in Canada.
“I think - [ writes Lloyd] - there are different ways to classify a “failure” of a standard. It has been precisely proven that it is possible to implement v3 (with the proper 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 assert their success:
• Market support was 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 very problematic. Canada, the United Kingdom, and the Netherlands have implemented v3-based drug formulations, but significant message conversions will be required to achieve compatibility [between these implementations ]. To a somewhat lesser extent, similar interaction problems exist between provinces in Canada. Some of them are caused by various 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 rather difficult to find those who are enthusiastic about the ease, speed and cost of implementing compatibility with HL7v3 (or CDA). Among those who enjoy this, v3 consultants are most often found. [ In particular, people like me, Lloyd writes. ]
I actually like v3 in terms of modeling it. The result is a very powerful modeling tool. But I came to the conclusion that the methodology and standards that come out of it do not bring a result comparable to the investment spent.
I am not saying that FHIR will be a panacea; it is still in development. But he is already able to solve some problems arising with v3, such as the complexity of training, overly complex messages, the differences between messages from different developers and the lack of an extension mechanism. And more importantly, it is gaining considerable strength among developers in an environment where no one can say for sure “so be it”, where different developers look at examples and say, “well, I can do that.” This is not at all what happened with v3 and in rare cases it happened with CDA.
Given the investments already made in v3 in Canada and the fact that FHIR is not yet 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 when or if suddenly we decide to switch to it. (I think FHIR is the only opportunity to ever see significant system compatibility between different jurisdictions.)
In conclusion [ Lloyd writes ]:
• I created numerous v3 models and implementation guides, trained v3 around the world and participated in several v3 projects. I was getting pretty good as a v3 consultant.
• Now I spend a lot of my time and that of my employer, working on FHIR on a voluntary basis. [ Further, Lloyd laments that in financial terms this is of little use. ] 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 a lot of consulting work on creating sensible developer guides, reaching consensus among interested parties (compatibility, in the end, is that interested parties agree on what part of the information can be transmitted), glossaries of terms, and so on. ”
=====
Actually, this can be completed. Perhaps someone was expecting a comparison of the two standards by points, under a microscope. But today, FHIR raises more questions than answers; there are no real, but not toy realizations, so comparing it is quite difficult. (There is no one from IBS, as I understand it, to tell you the extent to which Think! EHR supports FHIR, as declared on the vendor’s page.)