HL7 FHIR: Fast Healthcare Interoperability Resources
In this brief article about the causes of the emergence of the standard HL7 FHIR (Health Level 7 - Fast Healthcare Interoperability Resources) and the expected difficulties on this path.
And so, as a result of criticism from the developer community (for example, here ), as well as the likelihood of cuts in funding for the development of HL7v3 from the US HITECH (Health Information Technology for Economic and Clinical Health), January 2011 was marked by a new trend on how the HL7 messaging standard can be improved. This gave a free hand (and creativity) to an independent group of HL7 architects in discussing a new approach to sharing information in medical systems, which initially led to the emergence of RFH (Resources for Health), later renamed FHIR (Fast Healthcare Interoperability Resources).
This new approach is based on the principles of RESTful, as bequeathed by the great Roy Thomas Fielding in his 5th chapter. In theory (developers of the standard), FHIR is designed to simplify and accelerate the implementation of HL7, becoming much easier to implement and, at the same time, reliable and, as far as possible, based on open Internet standards.
')
Unlike HL7v2 and, to a greater extent, from HL7v3, the FHIR documentation contains examples of the implementation of all artifacts (resources) and links to their use in third-party projects on different platforms, including test servers available on the Internet. The HL7 group claims that HL7v3 will still not be thrown into the garbage of dead technologies, emphasizing that FHIR was created taking into account the experience with v3.
FHIR development process
While HL7v2 was developed using ad hoc methodology (also known as “God per person”), and HL7v3 followed a hard-coded, model-based process called HDF (HL7 Development Framework), FHIR uses an incremental and iterative approach to the development of a standard (usually so on the swamp from hummock to hummock make their way). The incremental approach is characterized by the development of small pieces of a standard per unit of time, which are immediately tested and, if successful, are incorporated back into the development process, after which the whole process is repeated.
FHIR artifacts
FHIR aims to identify the main entities in the medical field as resources in order to use them further in the exchange of medical data. Thus, each resource is a separate clearly identifiable entity, for example, Patient, Person, Location, Organization, etc. The FHIR specification, available at hl7.org/fhir, describes the following resource attributes:
• Resources must have clear boundaries that correspond to one or more logical areas.
• Resources should differ from each other in meaning, not in type of use. Thus, the possibility of different uses of the results of a lab analysis should not lead to the creation of a multitude of resources.
• Resources must have a clear identifier.
• Resources should represent common enough entities to be used in various medical / business areas.
• Resources should not be too specific or too detailed so as not to interfere with the use in various medical / business areas.
• Resources must be mutually exclusive [Although it is declared this way, but in practice I don’t see it, both Patient and Person are in a sense interchangeable. Perhaps it would be logical if the Patient resource contained a person element as a reference to the Person resource.] [1]
• Resources should use other resources, but this should not result in the composition of individual resources, but create new content.
• Resources must be organized into logical structures based on common resources and with which they are associated.
• Resources must be large enough to provide meaningful context. If a resource contains only a couple of attributes, then most likely it is too small to provide an adequate representation of the medical data.
At the time of this writing, 89 resources have been identified and this number is likely to grow. Firefighters (FHIRman) from HL7 suggest that there will eventually be about 150 resources. It is stated that the development of resources will be carried out similarly to v3, but at the same time the presentation of resources will remain fairly simple. Recall that in HL7v3, structures similar to resources have been defined for a long time and are called CMET (Common Message Element Types). If in the very first version of HL7v3, the number of CMET was 27, then in my latest version (NE 2014) there are 181. Hence, we can conclude that not all resources are yet identified, or the firefighters rethought some CMET and developed resources much more efficiently.
FHIR Criticism
In a resource-oriented environment like FHIR, it is very easy to implement basic artifacts, transfer them from one system to another, and store. Anyone familiar with the REST architecture can do it in a few minutes with test FHIR servers. However, it is not yet clear how simple resources will unite into larger structures with a large number of links. Also, nothing is said about supporting workflow in clinics outside of standard CRUD operations. This can lead to differences in the implementation and, as we have seen in the example of HL7v2 and the example of HL7v3, to the lack of interoperability (in other words, compatibility of medical systems).
For example, resources related to a collection of other resources, such as Composition or Bundle, are quite well defined in the standard, but more complex aggregates, such as Invoice, are not spelled out. (It can be said that this should not be spelled out in the standard, but such questions will appear in the very first week of the actual implementation of business processes.) At the time of this writing, concepts such as Document and Message, and their differences from aggregates (such as Composition ) is also not clearly spelled out. Moreover, it is argued that FHIR does not need all these messages at all, since REST architecture is designed for another.
However, such criticism is quite solvable in the framework of the development of the standard and depends only on the members of the FHIR group. But that does not depend on them, it is external factors, and they can be traced on the next cycle:
1. Developers create a standard that is the best you could think of at the moment (it was the same with HL7v2, and with HL7v3, and with CDA, and now with FHIR). Everyone is happy, everyone is happy.
2. But forcing the standard to multiply in a variety of implementations is quite a difficult task and the point here is often not in the technologies used. What is more important is to show how the standard fits into the organization’s daily working / business process, taking into account the protection of personal data, the internal political interests of various groups, demonstrating return on investment, etc. etc.
3. But we are not afraid of difficulties, so everyone, as one, is harnessed to the struggle for a bright future for the standard. However, this road is most often not the shortest and is littered with the corpses of the disillusioned. Only the strongest remain, many developers are bored.
4. In the fight against external factors, the standard developers do not always have time to create a sufficient number of development tools to work with the standard itself. But they always want to improve something, so they start ... looking at the most advanced technologies around them.
5. While (true) return to step # 1.
As it is not difficult to notice, the second point in this infinite loop is the most important. In order for FHIR to become successful, some monsters in the medical systems arena, especially in the USA, must decide to implement parallel interfaces with HL7v2 / HL7v3 and FHIR support, in the hope that developers will switch to FHIR for objective reasons (for example, lower financial costs interface support). I think many people look at the development of SMART-on-FHIR from Cerner Corporation in this perspective. This also includes the Argonaut Project supported by such famous players as Epic, Cerner, Meditech, McKesson and Mayo Clinic. You might also be interested in the draft versions of published IHE profiles - MHD (Mobile access to Health Documents) and PDQm (Patient Demographics Query for Mobile).
Well, in the end, indulge with the test FHIR server, and even the code will not have to be written, you can at - fhirtest.uhn.ca - these are the same guys who write HAPI for HL7v2, and now HAPI-FHIR.
For my part, I would like to see a story from the guys with fhirbase about the typical (and not very) architecture of the HL7 system based on FHIR, preferably with examples "it was so, it became so."
In the meantime, I will go to test the client interface written under DOS on pure C and working with the mainframe of the same age. The smoke from FHIR does not even smell there, either financially or technically. Yes, and HL7v2 there with a very strong non-standard accent (from the Z-segments of the eyes dazzled).
=====
1. Comment from Lloyd McKenzie about the Patient and Person and why they are so represented in FHIR DSTU2. It’s a combination of the individual systems and the population of individuals. role-independent. "
And so, as a result of criticism from the developer community (for example, here ), as well as the likelihood of cuts in funding for the development of HL7v3 from the US HITECH (Health Information Technology for Economic and Clinical Health), January 2011 was marked by a new trend on how the HL7 messaging standard can be improved. This gave a free hand (and creativity) to an independent group of HL7 architects in discussing a new approach to sharing information in medical systems, which initially led to the emergence of RFH (Resources for Health), later renamed FHIR (Fast Healthcare Interoperability Resources).
This new approach is based on the principles of RESTful, as bequeathed by the great Roy Thomas Fielding in his 5th chapter. In theory (developers of the standard), FHIR is designed to simplify and accelerate the implementation of HL7, becoming much easier to implement and, at the same time, reliable and, as far as possible, based on open Internet standards.
')
Unlike HL7v2 and, to a greater extent, from HL7v3, the FHIR documentation contains examples of the implementation of all artifacts (resources) and links to their use in third-party projects on different platforms, including test servers available on the Internet. The HL7 group claims that HL7v3 will still not be thrown into the garbage of dead technologies, emphasizing that FHIR was created taking into account the experience with v3.
FHIR development process
While HL7v2 was developed using ad hoc methodology (also known as “God per person”), and HL7v3 followed a hard-coded, model-based process called HDF (HL7 Development Framework), FHIR uses an incremental and iterative approach to the development of a standard (usually so on the swamp from hummock to hummock make their way). The incremental approach is characterized by the development of small pieces of a standard per unit of time, which are immediately tested and, if successful, are incorporated back into the development process, after which the whole process is repeated.
FHIR artifacts
FHIR aims to identify the main entities in the medical field as resources in order to use them further in the exchange of medical data. Thus, each resource is a separate clearly identifiable entity, for example, Patient, Person, Location, Organization, etc. The FHIR specification, available at hl7.org/fhir, describes the following resource attributes:
• Resources must have clear boundaries that correspond to one or more logical areas.
• Resources should differ from each other in meaning, not in type of use. Thus, the possibility of different uses of the results of a lab analysis should not lead to the creation of a multitude of resources.
• Resources must have a clear identifier.
• Resources should represent common enough entities to be used in various medical / business areas.
• Resources should not be too specific or too detailed so as not to interfere with the use in various medical / business areas.
• Resources must be mutually exclusive [Although it is declared this way, but in practice I don’t see it, both Patient and Person are in a sense interchangeable. Perhaps it would be logical if the Patient resource contained a person element as a reference to the Person resource.] [1]
• Resources should use other resources, but this should not result in the composition of individual resources, but create new content.
• Resources must be organized into logical structures based on common resources and with which they are associated.
• Resources must be large enough to provide meaningful context. If a resource contains only a couple of attributes, then most likely it is too small to provide an adequate representation of the medical data.
At the time of this writing, 89 resources have been identified and this number is likely to grow. Firefighters (FHIRman) from HL7 suggest that there will eventually be about 150 resources. It is stated that the development of resources will be carried out similarly to v3, but at the same time the presentation of resources will remain fairly simple. Recall that in HL7v3, structures similar to resources have been defined for a long time and are called CMET (Common Message Element Types). If in the very first version of HL7v3, the number of CMET was 27, then in my latest version (NE 2014) there are 181. Hence, we can conclude that not all resources are yet identified, or the firefighters rethought some CMET and developed resources much more efficiently.
FHIR Criticism
In a resource-oriented environment like FHIR, it is very easy to implement basic artifacts, transfer them from one system to another, and store. Anyone familiar with the REST architecture can do it in a few minutes with test FHIR servers. However, it is not yet clear how simple resources will unite into larger structures with a large number of links. Also, nothing is said about supporting workflow in clinics outside of standard CRUD operations. This can lead to differences in the implementation and, as we have seen in the example of HL7v2 and the example of HL7v3, to the lack of interoperability (in other words, compatibility of medical systems).
For example, resources related to a collection of other resources, such as Composition or Bundle, are quite well defined in the standard, but more complex aggregates, such as Invoice, are not spelled out. (It can be said that this should not be spelled out in the standard, but such questions will appear in the very first week of the actual implementation of business processes.) At the time of this writing, concepts such as Document and Message, and their differences from aggregates (such as Composition ) is also not clearly spelled out. Moreover, it is argued that FHIR does not need all these messages at all, since REST architecture is designed for another.
However, such criticism is quite solvable in the framework of the development of the standard and depends only on the members of the FHIR group. But that does not depend on them, it is external factors, and they can be traced on the next cycle:
1. Developers create a standard that is the best you could think of at the moment (it was the same with HL7v2, and with HL7v3, and with CDA, and now with FHIR). Everyone is happy, everyone is happy.
2. But forcing the standard to multiply in a variety of implementations is quite a difficult task and the point here is often not in the technologies used. What is more important is to show how the standard fits into the organization’s daily working / business process, taking into account the protection of personal data, the internal political interests of various groups, demonstrating return on investment, etc. etc.
3. But we are not afraid of difficulties, so everyone, as one, is harnessed to the struggle for a bright future for the standard. However, this road is most often not the shortest and is littered with the corpses of the disillusioned. Only the strongest remain, many developers are bored.
4. In the fight against external factors, the standard developers do not always have time to create a sufficient number of development tools to work with the standard itself. But they always want to improve something, so they start ... looking at the most advanced technologies around them.
5. While (true) return to step # 1.
As it is not difficult to notice, the second point in this infinite loop is the most important. In order for FHIR to become successful, some monsters in the medical systems arena, especially in the USA, must decide to implement parallel interfaces with HL7v2 / HL7v3 and FHIR support, in the hope that developers will switch to FHIR for objective reasons (for example, lower financial costs interface support). I think many people look at the development of SMART-on-FHIR from Cerner Corporation in this perspective. This also includes the Argonaut Project supported by such famous players as Epic, Cerner, Meditech, McKesson and Mayo Clinic. You might also be interested in the draft versions of published IHE profiles - MHD (Mobile access to Health Documents) and PDQm (Patient Demographics Query for Mobile).
Well, in the end, indulge with the test FHIR server, and even the code will not have to be written, you can at - fhirtest.uhn.ca - these are the same guys who write HAPI for HL7v2, and now HAPI-FHIR.
For my part, I would like to see a story from the guys with fhirbase about the typical (and not very) architecture of the HL7 system based on FHIR, preferably with examples "it was so, it became so."
In the meantime, I will go to test the client interface written under DOS on pure C and working with the mainframe of the same age. The smoke from FHIR does not even smell there, either financially or technically. Yes, and HL7v2 there with a very strong non-standard accent (from the Z-segments of the eyes dazzled).
=====
1. Comment from Lloyd McKenzie about the Patient and Person and why they are so represented in FHIR DSTU2. It’s a combination of the individual systems and the population of individuals. role-independent. "
Source: https://habr.com/ru/post/260145/
All Articles