Difference between revisions of "FHIR Implementation Guide"

From Clinfowiki
Jump to: navigation, search
 
Line 1: Line 1:
−
What is FHIR?
 
−
FHIR is the newest HL7 open standard for interoperability called Fast Healthcare Interoperability Resource. FHIR uses web-based technologies such as XML, HTTP, JSON, and application programming interface (API). Small packages of standard healthcare information are used to create resources which are the unit of exchange of information within FHIR. FHIR also has resources for terminology/ontology standards which can be used to provide referential integrity within the FHIR network. Similarly to most web-based applications, FHIR tries to comply with REST (Representation State Transfer) principles. One of the major principles of REST is client-server separation. This way the client can be a user-facing thin application that handles the presentation. Servers can be a direct source of information such as databases or could have a separate middle layer executing queries and exchanging the flow of information from the client to the database. (1, 2)
 
  
−
21st Century Cures Act defines Electronic Health information (EHI) and information blocking. According to the law, to not be information blockers, healthcare providers and organizations must provide patients with APIs (application programming interfaces) to access their electronic health information. (3) FHIR (Fast Healthcare interoperability resource) is chosen to be the default standard for providing this service. Office of national coordinator (ONC) for Health Information Technology (HIT) publishes USCDI (United States Core Data Interoperability, current version V3) that defines the set of data elements required to be shared with patients. (4) To be compliant with this regulatory framework, many organizations have to make changes to the way their current clinical practice and Electronic Health Record is set up. In this article, I want to explore the implementation of FHIR-based interoperability standards to share information with patients electronically.
+
21st Century Cures Act defines Electronic Health information (EHI) and information blocking. According to the law, to not be information blockers, healthcare providers and organizations must provide patients with APIs (application programming interfaces) to access their electronic health information. (1) FHIR (Fast Healthcare interoperability resource) is chosen to be the default standard for providing this service. Office of National Coordinator (ONC) for Health Information Technology (HIT) publishes USCDI (United States Core Data Interoperability, current version V3) that defines the set of data elements required to be shared with patients. (2) To be compliant with this regulatory framework, many organizations have to make changes to the way their current clinical practice and Electronic Health Record is set up. In this article, I want to explore the implementation of FHIR-based interoperability standards to share information with patients electronically.
  
  
−
'''Architecture'''
 
  
−
''FHIR server''  
+
== '''What is FHIR?''' ==
  
−
In healthcare, data is variable and inconsistent. This provides a challenge in knowing if the information that is being shared is the right information. To resolve this issue, FHIR servers can be structured in several different ways. One potential way would be to create a middle layer that can convert internal data structures to FHIR-compatible data. Another way would be to create a separate general-purpose database that could take the data out of the internal system to a separate FHIR-compatible database. The advantage here is that it would avoid putting a load on the internal servers which are designed for day-to-day transactions of the organization/clinic. Finally, the internal system could be structured in a FHIR-compatible format. Each method has its advantages and costs associated. (5) The final option is costly and involves a lot of work, but it provides maximum interoperability down the line.
+
FHIR is the newest HL7 open standard for interoperability called Fast Healthcare Interoperability Resource. FHIR uses web-based technologies such as XML, HTTP, JSON, and application programming interface (API). Small packages of standard healthcare information are used to create resources which are the unit of exchange of information within FHIR. FHIR also has resources for terminology/ontology standards which can be used to provide referential integrity within the FHIR network. Similarly to most web-based applications, FHIR tries to comply with REST (Representation State Transfer) principles. One of the major principles of REST is client-server separation. This way the client can be a user-facing thin application that handles the presentation. Servers can be a direct source of information such as databases or could have a separate middle layer executing queries and exchanging the flow of information from the client to the database. (3, 4)
  
−
Here, I want to take an example case where we would share patients’ test results with them electronically. Let’s say in the current environment, our clinical practice has no way of sharing healthcare information with patients electronically. When the patient's test results are available, physicians write a letter and physically mail it to the patients. To be more transparent as a regulatory requirement and also make the workflow easier for our providers, we want to set up an electronic/digital system to share patients’ test results as soon as they are available. Implementing a separate FHIR-compatible server allows us to be able to deal with API authorization and access-related issues and use the data from the EHR database that needs to be shared with the patient. Furthermore, making this investment now will make integrating future applications/use case requirements less expensive and easier.
 
  
−
''Mapping Layer''
+
== '''Architecture''' ==
 +
 +
 
 +
'''''FHIR server'''''
 +
 
 +
In healthcare, data is variable and inconsistent. This provides a challenge in knowing if the information that is being shared is the right information. To resolve this issue, FHIR servers can be structured in several different ways. One potential way would be to create a middle layer that can convert internal data structures to FHIR-compatible data. Another way would be to create a separate general-purpose database that could take the data out of the internal system to a separate FHIR-compatible database. The advantage here is that it would avoid putting a load on the internal servers which are designed for day-to-day transactions of the organization/clinic. Finally, the internal system could be structured in a FHIR-compatible format. Each method has its advantages and costs associated. (5) The final option is costly and involves a lot of work, but it provides maximum interoperability eventually.
 +
 
 +
 
 +
Here, I want to take an example case where we would share patients’ test results with them electronically. Let’s say in the current environment, our clinical practice has no way of sharing healthcare information with patients electronically. When the patient's test results are available, physicians write a letter and physically mail it to the patients. To be more transparent as a regulatory requirement and also make the workflow easier for our providers, we want to set up an electronic/digital system to share patients’ test results as soon as they are available. Any methods mentioned above can be chosen to make our data models FHIR compatible. Implementing a separate FHIR-compatible server now would also allow us to be able to deal with API authorization and access-related issues on a separate server, in addition to being able to use the data from the EHR database that needs to be shared with the patient. Furthermore, making such an investment will make integrating future applications/use case requirements less expensive and easier.
 +
 
 +
 
 +
'''''Mapping Layer'''''
 +
 
 +
The data in an EHR could be stored as a hierarchical or relational database. Typically, hierarchical databases are used for minute-to-minute access and this data is then transformed into a relational database for storage and analytics which is updated regularly (6). We will need to create a mapping layer that will link the data (for example test results) in the underlying EHR to FHIR resources which is how the data will be presented to the patients.
  
−
The data in our EHR could be stored as hierarchical or relational database. Typically, hierarchical databases are used for minute-to-minute access and this data is then transformed into a relational database for storage and analytics which is updated regularly (6). We will need to create a mapping layer that will link the data (for example test results) in the underlying EHR to FHIR resources which is how the data will be presented to the patients.
 
  
 
This can be achieved using LOINC codes. LOINC (Logical Observation Identifiers Names and Codes) is a widely used code scheme for laboratory test names and clinical observations. The code is a sequence number with a check digit. The formal name has six parts (component, property, time, system, scale, and method, which is optional). Laboratory LOINC covers observations about specimens, while clinical LOINC covers observations about people, including survey instruments. LOINC is available for free to implement. (7, 8)  
 
This can be achieved using LOINC codes. LOINC (Logical Observation Identifiers Names and Codes) is a widely used code scheme for laboratory test names and clinical observations. The code is a sequence number with a check digit. The formal name has six parts (component, property, time, system, scale, and method, which is optional). Laboratory LOINC covers observations about specimens, while clinical LOINC covers observations about people, including survey instruments. LOINC is available for free to implement. (7, 8)  
 +
  
 
FHIR provides resources for LOINC codes within its structure. (9) LOINC codes provide machine-readable standardization for the observations. However, LOINC codes aren’t perfect, and automated implementations of LOINC codes have been associated with inaccuracies. (10) Data elements and mappings will need to be validated manually to make sure that the information in the resources is the same as the information linked in the EHR.   
 
FHIR provides resources for LOINC codes within its structure. (9) LOINC codes provide machine-readable standardization for the observations. However, LOINC codes aren’t perfect, and automated implementations of LOINC codes have been associated with inaccuracies. (10) Data elements and mappings will need to be validated manually to make sure that the information in the resources is the same as the information linked in the EHR.   
  
−
''Resources layer''
 
  
−
We will need several types of resources to render test results available to the patients. To create a resource layer on the FHIR server, we will need schemas with specifications for different resources. (11) These can be obtained from the HL7 FHIR build website where they are available in XML and JSON. (12) Additional documentation can be found on the HL7 FHIR website with details about the resource structures. HL7 FHIR website also contains details about the US core implementation guidelines. (13) This guides what information is required vs what is optional within US FHIR implementation standards. Figure (1.1) shows an example “Patient” resource created using the HL7 FHIR JSON schema which can then be posted onto the FHIR server (posted on the test HAPI FHIR server here [http://hapi.fhir.org/baseR4]).
+
'''''Resources layer'''''
  
−
(Figure 1.1)
+
We will need several different resources to render test results available to the patients. To create a resource layer on the FHIR server, we will need schemas with specifications for different resources. These can be obtained from the HL7 FHIR build website ( [https://build.fhir.org/downloads.html] ) where they are available in XML and JSON. Additional documentation can be found on the HL7 FHIR website with details about the resource structures. HL7 FHIR website ( [https://www.hl7.org/fhir/us/core/] ) also contains details about the US core implementation guidelines. This guides what information is required vs what is optional within US FHIR implementation standards.
  
−
Once posted, if all the specifications are accurate you will see that the resource is created. We can also see that once posted on the FHIR server, a new server-specific ID (figure 1.2) is created automatically. This can be used for other specific FHIR operations such as searching, updating, or deleting this specific resource. This ID can be used as a reference to create an Observation Resource for this patient (figure 1.3).
 
  
−
(Figure 1.2)
+
For our example case, we will need a “Patient” resource which can be created in either XML or JSON and posted on the server. Once posted, if all the specifications are accurate you will see that the resource is created, and a new server-specific ID is created automatically. This ID can be used for other specific FHIR operations such as searching, updating, or deleting this specific resource. This ID can also be used as a reference to create other resources such as an “Observation” resource for the same patient. Here's the link ( [https://www.youtube.com/playlist?list=PLUr-PTsPYKV4SHhszovqJ3v4hEhRezqzo] )to a demo for creating and posting resources on a server.
  
−
(Figure 1.3)
 
  
−
For our example case, one of the major resource types we will require is the DiagnosticReport. The DiagnosticReport resource (14) has information about the subject, test done, and results with further details such as images. Report conclusions can be expressed as a simple text blob, structured coded data, or reports in PDF format. Another resource we will require is an Observation resource. “Observations are a central element in healthcare, used to support diagnosis, monitor progress, determine baselines and patterns, and even capture demographic characteristics, as well as capture results of tests performed on products and substances. Most observations are simple name/value pair assertions with some metadata, but some observations group other observations together logically, or even are multi-component observations.” (15) The DiagnosticReport provides a clinical or workflow context for a set of observations. Diagnostic resources typically refer to observation resources to form a complete report.  
+
Another major resource type we will require to share test results with patients is the “DiagnosticReport”. The “DiagnosticReport” resource (11) has information about the subject, test done, and results with further details such as images. Report conclusions can be expressed as a simple text blob, structured coded data, or reports in PDF format. Another resource that will be required is an “Observation” resource. “Observations are a central element in healthcare, used to support diagnosis, monitor progress, determine baselines and patterns, and even capture demographic characteristics, as well as capture results of tests performed on products and substances. Most observations are simple name/value pair assertions with some metadata, but some observations group other observations together logically, or even are multi-component observations.” (12) The DiagnosticReport provides a clinical or workflow context for a set of observations. Diagnostic resources typically refer to observation resources to form a complete report.
  
−
The figure below (created on [http://gb2.clinfhir.com/]) shows a graph of how different resources are structured around diagnostic reports to create a CBC report. (16) This graph also contains other resources such as “Patient” (who the test is about), “ServiceRequest” (what type of order it was), and “Practitioner” (who ordered the test). Once these resources are compiled in the FHIR server they can be accessed by an application using the API layer using the patient’s identifier. The search for a specific test within applications can be further narrowed down by using search criteria to include the type of the test and observation date.  
+
 +
A schema describing how different resources would be used for a specific case can be made on http://gb2.clinfhir.com/ which is an open-source tool. Here's a link ( [https://fhirblog.com/2021/05/23/accessing-lab-data-via-fhir-part-1/] ) to a blog demonstrating how to do this. For example, a CBC report is an example of a DiagnosticReport resource, which will reference multiple “observation” resources (WBC, Hgb, Plt), “Patient” (who the test is about), “ServiceRequest” (what type of order it was), and “Practitioner” (who ordered the test). Once these resources are compiled in the FHIR server they can be accessed by an application using the API layer using the patient’s identifier. The search for a specific test within applications can be further narrowed down by using search criteria to include the type of the test and observation date.  
  
−
(Figure 2)
 
  
−
'''Integration with SMART on FHIR'''
 
  
−
Now that we have the FHIR server and the required resources, we need a method to access these resources and present them to the patients in a user-friendly way safely and securely. This is where SMART on FHIR comes into the picture. SMART is an acronym for substitutable medical apps and reusable technologies. SMART was developed by an informatics group at the Boston Children’s Hospital. It is open API specifications for EHR data access, with a SMART app platform. SMART is built on top of the FHIR platform. It adds constraints to the FHIR with a standard set of data profiles and adds standard authorization and authentication technologies (OAuth 2.0 and OpenID Connect) to provide a security layer. (17) SMART on the FHIR protocol allows integration of the FHIR server with both mobile and desktop applications. We can also integrate mobile platform applications since they provide wider access to services for patients who do not have personal computers. There are plenty of commercial API services now available such as Microsoft Azure API which leverage the SMART on the FHIR platform and make it even easier to develop this interface. (18)
+
== '''Integration with SMART on FHIR''' ==
  
−
'''Security'''
 
  
−
Privacy is the right of individuals to have some control over information about themselves. Many countries have laws designed to protect privacy (for example HIPAA in the USA), and every organization that collects and stores information about individuals is legally obliged to adopt policies that conform to local privacy legislation. IT designs adopted by organizations should reflect the organization’s commitment to the protection of individual privacy rights by including only those items that the organization has a right to know and keeping them secure. Violation of any of these practices and regulations can lead to fraud, financial losses, and severe penalties. (19)
 
  
−
FHIR itself isn’t a security protocol and implementation of FHIR doesn’t require security protocols implementation. It is up to the implementers to ensure adequate security protocols are in place to safeguard healthcare data. Here are some of the mechanisms which can ensure healthcare information security: (20)
+
Now that we have the FHIR server and the required resources, we need a method to access these resources and present them to the patients in a user-friendly way safely and securely. This is where SMART on FHIR comes into the picture. SMART is an acronym for substitutable medical apps and reusable technologies. SMART was developed by an informatics group at the Boston Children’s Hospital. It is open API specifications for EHR data access, with a SMART app platform. SMART is built on top of the FHIR platform. It adds constraints to the FHIR with a standard set of data profiles and adds standard authorization and authentication technologies (OAuth 2.0 and OpenID Connect) to provide a security layer. (13) SMART on the FHIR protocol allows integration of the FHIR server with both mobile and desktop applications. We can also integrate mobile platform applications since they provide wider access to services for patients who do not have personal computers. There are plenty of commercial API services now available such as Microsoft Azure API which leverage the SMART on the FHIR platform and make it even easier to develop this interface. (14)
  
−
''Encryption''
 
  
−
Encrypting the information at the transport layer (TLS) of the internet using Hyper Text Transfer Protocol Secure (HTTPS) for secure transmission. This can prevent deliberate interception and tampering of medical record data between the two systems. (21)
+
'''''Security'''''
  
−
''Authorization and Authentication''
+
Privacy is the right of individuals to have some control over information about themselves. Many countries have laws designed to protect privacy (for example HIPAA in the USA), and every organization that collects and stores information about individuals is legally obliged to adopt policies that conform to local privacy legislation. IT designs adopted by organizations should reflect the organization’s commitment to the protection of individual privacy rights by including only those items that the organization has a right to know and keeping them secure. Violation of any of these practices and regulations can lead to fraud, financial losses, and severe penalties. (15)
  
−
Access control with the use of authentication and authorization protocols as described in SMART on FHIR implementation. OAuth is an open protocol to allows secure authorization in a simple and standard manner from web, mobile, and desktop applications. The following figure shows how SMART on FHIR employs authorization protocols to get access to the information. To authorize access, first, the subject needs to be identified which can be done by using an authentication protocol such as OpenID Connect. This authorization and authentication protocol could be implemented at either one or all of the client, server, or database/repository levels. 
 
  
−
(Figure 3)
+
FHIR itself isn’t a security protocol and implementation of FHIR doesn’t require security protocols implementation. It is up to the implementers to ensure adequate security protocols are in place to safeguard healthcare data. Here are some of the mechanisms which can ensure healthcare information security: (16)
  
−
''Security Labels''
 
  
−
Security labels are another means to control access. These tags can be embedded within the resources specifying access rules as appropriate by granting or rejecting access. A few examples are general confidentiality level (Low to Very restricted), the patient is a celebrity or a staff member, information is not to be shared with the patient, or with their family, the information relates to sensitive medical diagnoses (STD and mental illness). (20)
+
'''''Encryption'''''
  
−
''Provenance and Audits''
+
Encrypting the information at the transport layer (TLS) of the internet using Hyper Text Transfer Protocol Secure (HTTPS) for secure transmission. This can prevent deliberate interception and tampering of medical record data between the two systems. (17)
 +
 
 +
 
 +
'''''Authorization and Authentication'''''
 +
 
 +
Access control with the use of authentication and authorization protocols is described in SMART on FHIR implementation. OAuth is an open protocol that allows secure authorization in a simple and standard manner from web, mobile, and desktop applications. To authorize access, first, the subject needs to be identified which can be done by using an authentication protocol such as OpenID Connect. This authorization and authentication protocol could be implemented at either one or all of the client, server, or database/repository levels. Here's a guide ( [https://build.fhir.org/ig/HL7/smart-app-launch/app-launch.html] ) for SMART on FHIR authorization and app launch process.
 +
 +
 
 +
'''''Security Labels'''''
 +
 
 +
Security labels are another means to control access. These tags can be embedded within the resources specifying access rules as appropriate by granting or rejecting access. A few examples are general confidentiality level (Low to Very restricted), the patient is a celebrity or a staff member, information is not to be shared with the patient, or with their family, the information relates to sensitive medical diagnoses (STD and mental illness). (16)
 +
 
 +
 
 +
 
 +
'''''Provenance and Audits'''''
  
 
These are some of the resources in FHIR that can be implemented to track who has accessed the system and what information was exchanged.  
 
These are some of the resources in FHIR that can be implemented to track who has accessed the system and what information was exchanged.  
 
Finally, and most importantly, a separate governance group must be created to ensure these security measures are utilized and implemented properly for the project.   
 
Finally, and most importantly, a separate governance group must be created to ensure these security measures are utilized and implemented properly for the project.   
  
−
'''Evaluations'''
+
 
 +
 
 +
== '''Evaluations''' ==
  
 
Evaluations must be done to ensure the system is implemented the way it is intended. Implementers will need to evaluate the results on the patient-facing side in a test environment. The major validation requirement would be to make sure mappings are accurate by manual review of any automated implementations. Additionally, the security measures implemented above would need to be evaluated before going live.   
 
Evaluations must be done to ensure the system is implemented the way it is intended. Implementers will need to evaluate the results on the patient-facing side in a test environment. The major validation requirement would be to make sure mappings are accurate by manual review of any automated implementations. Additionally, the security measures implemented above would need to be evaluated before going live.   
  
−
'''Conclusion'''
+
 
 +
 
 +
== '''Conclusion''' ==
  
 
In today’s digital age, patients must be provided with their information accurately and promptly. Providing this digitally makes it easier for patients to keep their health records safe and available as opposed to paper versions. Creating such a system would also make further interoperability with patient, provider-facing applications easier in the future.  
 
In today’s digital age, patients must be provided with their information accurately and promptly. Providing this digitally makes it easier for patients to keep their health records safe and available as opposed to paper versions. Creating such a system would also make further interoperability with patient, provider-facing applications easier in the future.  
  
  
−
'''References'''
 
  
−
1. Benson T, Grieve G. Principles of FHIR. In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 79-102.
+
=='''References''' ==
 +
   
  
−
2. Ricardo CM, Urban S, Davis K. Databases illuminated, Chapter 12. Fourth edition. ed. Burlington, MA: Jones & Bartlett Learning; 2022.    
+
1. HealthIT.gov 21st Century Cures Act  [Available from: [https://www.healthit.gov/topic/information-blocking].
  
−
3. HealthIT.gov 21st Century Cures Act  [Available from: [https://www.healthit.gov/topic/information-blocking].
+
2.     USCDI V3 [Available from : [https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v3].
  
−
4.     USCDI V3 [Available from : [https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#uscdi-v3].
+
3. Benson T, Grieve G. Principles of FHIR. In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 79-102.
 +
 
 +
4. Ricardo CM, Urban S, Davis K. Databases illuminated, Chapter 12. Fourth edition. ed. Burlington, MA: Jones & Bartlett Learning; 2022.
  
 
5. Benson T, Grieve G. Implementing FHIRFast Healthcare Interoperability Resources (FHIR). In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 173-91.
 
5. Benson T, Grieve G. Implementing FHIRFast Healthcare Interoperability Resources (FHIR). In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 173-91.
Line 99: Line 119:
 
10. LOINC Risks [Available from: [https://www.thelancet.com/journals/landig/article/PIIS2589-7500(20)30244-2/fulltext].
 
10. LOINC Risks [Available from: [https://www.thelancet.com/journals/landig/article/PIIS2589-7500(20)30244-2/fulltext].
  
−
11. FHIR implementation demo [Available from: [https://www.youtube.com/playlist?list=PLUr-PTsPYKV4SHhszovqJ3v4hEhRezqzo].
+
11. Resource Diagnostic Report  [Available from: [https://build.fhir.org/diagnosticreport.html].
  
−
12. FHIR builds schemas [Available from: [https://build.fhir.org/downloads.html].
+
12. Resource Observation [Available from: [https://build.fhir.org/observation.html].
  
−
13. FHIR US core implementation guide  [Available from: [https://www.hl7.org/fhir/us/core/].
+
13. Bloomfield RA, Jr., Polo-Wood F, Mandel JC, Mandl KD. Opening the Duke electronic health record to apps: Implementing SMART on FHIR. Int J Med Inform. 2017;99:1-10.
  
−
14. Resource Diagnostic Report [Available from: [https://build.fhir.org/diagnosticreport.html].
+
14. SMARTHEALTHIT [Available from: [https://smarthealthit.org/smart-on-fhir-api/#:~:text=SMART%20on%20FHIR%2C%20provides%20a,varied%20regions%20and%20use%20cases].
  
−
15. Resource Observation  [Available from: [https://build.fhir.org/observation.html].
+
15. Ricardo CM, Urban S, Davis K. Databases illuminated, Chapter 8. Fourth edition. ed. Burlington, MA: Jones & Bartlett Learning; 2022.
  
−
16. Hay D. [Available from: [https://fhirblog.com/2021/05/23/accessing-lab-data-via-fhir-part-1/].
+
16. Benson T, Grieve G. Security Security& Integrity in FHIRFast Healthcare Interoperability Resources (FHIR). In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 193-210.
  
−
17. Bloomfield RA, Jr., Polo-Wood F, Mandel JC, Mandl KD. Opening the Duke electronic health record to apps: Implementing SMART on FHIR. Int J Med Inform. 2017;99:1-10.
+
17. Liu TJ, Lee HT, Wu F. Building an Electronic Medical Record System Exchanged in FHIR Format and Its Visual Presentation. Healthcare (Basel). 2023;11(17).
  
−
18. SMARTHEALTHIT  [Available from: [https://smarthealthit.org/smart-on-fhir-api/#:~:text=SMART%20on%20FHIR%2C%20provides%20a,varied%20regions%20and%20use%20cases].
 
  
−
19. Ricardo CM, Urban S, Davis K. Databases illuminated, Chapter 8. Fourth edition. ed. Burlington, MA: Jones & Bartlett Learning; 2022.
+
Submitted by (Ritchie Verma, MD)
  
−
20. Benson T, Grieve G. Security Security& Integrity in FHIRFast Healthcare Interoperability Resources (FHIR). In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 193-210.
+
[[Category:BMI512-SPRING-24]]
  
−
21. Liu TJ, Lee HT, Wu F. Building an Electronic Medical Record System Exchanged in FHIR Format and Its Visual Presentation. Healthcare (Basel). 2023;11(17).
+
--[[User:RitchieVerma|RitchieVerma]] ([[User talk:RitchieVerma|talk]]) 16:48, 1 May 2024 (UTC)
−
 
+
−
 
+
−
Submitted by (Ritchie Verma, MD)
+
−
[[Category:BMI512-SPRING-24]]
+
−
--[[User:RitchieVerma|RitchieVerma]] ([[User talk:RitchieVerma|talk]]) 19:26, 30 April 2024 (UTC)
+

Latest revision as of 16:48, 1 May 2024

21st Century Cures Act defines Electronic Health information (EHI) and information blocking. According to the law, to not be information blockers, healthcare providers and organizations must provide patients with APIs (application programming interfaces) to access their electronic health information. (1) FHIR (Fast Healthcare interoperability resource) is chosen to be the default standard for providing this service. Office of National Coordinator (ONC) for Health Information Technology (HIT) publishes USCDI (United States Core Data Interoperability, current version V3) that defines the set of data elements required to be shared with patients. (2) To be compliant with this regulatory framework, many organizations have to make changes to the way their current clinical practice and Electronic Health Record is set up. In this article, I want to explore the implementation of FHIR-based interoperability standards to share information with patients electronically.


What is FHIR?

FHIR is the newest HL7 open standard for interoperability called Fast Healthcare Interoperability Resource. FHIR uses web-based technologies such as XML, HTTP, JSON, and application programming interface (API). Small packages of standard healthcare information are used to create resources which are the unit of exchange of information within FHIR. FHIR also has resources for terminology/ontology standards which can be used to provide referential integrity within the FHIR network. Similarly to most web-based applications, FHIR tries to comply with REST (Representation State Transfer) principles. One of the major principles of REST is client-server separation. This way the client can be a user-facing thin application that handles the presentation. Servers can be a direct source of information such as databases or could have a separate middle layer executing queries and exchanging the flow of information from the client to the database. (3, 4)


Architecture

FHIR server

In healthcare, data is variable and inconsistent. This provides a challenge in knowing if the information that is being shared is the right information. To resolve this issue, FHIR servers can be structured in several different ways. One potential way would be to create a middle layer that can convert internal data structures to FHIR-compatible data. Another way would be to create a separate general-purpose database that could take the data out of the internal system to a separate FHIR-compatible database. The advantage here is that it would avoid putting a load on the internal servers which are designed for day-to-day transactions of the organization/clinic. Finally, the internal system could be structured in a FHIR-compatible format. Each method has its advantages and costs associated. (5) The final option is costly and involves a lot of work, but it provides maximum interoperability eventually.


Here, I want to take an example case where we would share patients’ test results with them electronically. Let’s say in the current environment, our clinical practice has no way of sharing healthcare information with patients electronically. When the patient's test results are available, physicians write a letter and physically mail it to the patients. To be more transparent as a regulatory requirement and also make the workflow easier for our providers, we want to set up an electronic/digital system to share patients’ test results as soon as they are available. Any methods mentioned above can be chosen to make our data models FHIR compatible. Implementing a separate FHIR-compatible server now would also allow us to be able to deal with API authorization and access-related issues on a separate server, in addition to being able to use the data from the EHR database that needs to be shared with the patient. Furthermore, making such an investment will make integrating future applications/use case requirements less expensive and easier.


Mapping Layer

The data in an EHR could be stored as a hierarchical or relational database. Typically, hierarchical databases are used for minute-to-minute access and this data is then transformed into a relational database for storage and analytics which is updated regularly (6). We will need to create a mapping layer that will link the data (for example test results) in the underlying EHR to FHIR resources which is how the data will be presented to the patients.


This can be achieved using LOINC codes. LOINC (Logical Observation Identifiers Names and Codes) is a widely used code scheme for laboratory test names and clinical observations. The code is a sequence number with a check digit. The formal name has six parts (component, property, time, system, scale, and method, which is optional). Laboratory LOINC covers observations about specimens, while clinical LOINC covers observations about people, including survey instruments. LOINC is available for free to implement. (7, 8)


FHIR provides resources for LOINC codes within its structure. (9) LOINC codes provide machine-readable standardization for the observations. However, LOINC codes aren’t perfect, and automated implementations of LOINC codes have been associated with inaccuracies. (10) Data elements and mappings will need to be validated manually to make sure that the information in the resources is the same as the information linked in the EHR.


Resources layer

We will need several different resources to render test results available to the patients. To create a resource layer on the FHIR server, we will need schemas with specifications for different resources. These can be obtained from the HL7 FHIR build website ( [1] ) where they are available in XML and JSON. Additional documentation can be found on the HL7 FHIR website with details about the resource structures. HL7 FHIR website ( [2] ) also contains details about the US core implementation guidelines. This guides what information is required vs what is optional within US FHIR implementation standards.


For our example case, we will need a “Patient” resource which can be created in either XML or JSON and posted on the server. Once posted, if all the specifications are accurate you will see that the resource is created, and a new server-specific ID is created automatically. This ID can be used for other specific FHIR operations such as searching, updating, or deleting this specific resource. This ID can also be used as a reference to create other resources such as an “Observation” resource for the same patient. Here's the link ( [3] )to a demo for creating and posting resources on a server.


Another major resource type we will require to share test results with patients is the “DiagnosticReport”. The “DiagnosticReport” resource (11) has information about the subject, test done, and results with further details such as images. Report conclusions can be expressed as a simple text blob, structured coded data, or reports in PDF format. Another resource that will be required is an “Observation” resource. “Observations are a central element in healthcare, used to support diagnosis, monitor progress, determine baselines and patterns, and even capture demographic characteristics, as well as capture results of tests performed on products and substances. Most observations are simple name/value pair assertions with some metadata, but some observations group other observations together logically, or even are multi-component observations.” (12) The DiagnosticReport provides a clinical or workflow context for a set of observations. Diagnostic resources typically refer to observation resources to form a complete report.


A schema describing how different resources would be used for a specific case can be made on http://gb2.clinfhir.com/ which is an open-source tool. Here's a link ( [4] ) to a blog demonstrating how to do this. For example, a CBC report is an example of a DiagnosticReport resource, which will reference multiple “observation” resources (WBC, Hgb, Plt), “Patient” (who the test is about), “ServiceRequest” (what type of order it was), and “Practitioner” (who ordered the test). Once these resources are compiled in the FHIR server they can be accessed by an application using the API layer using the patient’s identifier. The search for a specific test within applications can be further narrowed down by using search criteria to include the type of the test and observation date.


Integration with SMART on FHIR

Now that we have the FHIR server and the required resources, we need a method to access these resources and present them to the patients in a user-friendly way safely and securely. This is where SMART on FHIR comes into the picture. SMART is an acronym for substitutable medical apps and reusable technologies. SMART was developed by an informatics group at the Boston Children’s Hospital. It is open API specifications for EHR data access, with a SMART app platform. SMART is built on top of the FHIR platform. It adds constraints to the FHIR with a standard set of data profiles and adds standard authorization and authentication technologies (OAuth 2.0 and OpenID Connect) to provide a security layer. (13) SMART on the FHIR protocol allows integration of the FHIR server with both mobile and desktop applications. We can also integrate mobile platform applications since they provide wider access to services for patients who do not have personal computers. There are plenty of commercial API services now available such as Microsoft Azure API which leverage the SMART on the FHIR platform and make it even easier to develop this interface. (14)


Security

Privacy is the right of individuals to have some control over information about themselves. Many countries have laws designed to protect privacy (for example HIPAA in the USA), and every organization that collects and stores information about individuals is legally obliged to adopt policies that conform to local privacy legislation. IT designs adopted by organizations should reflect the organization’s commitment to the protection of individual privacy rights by including only those items that the organization has a right to know and keeping them secure. Violation of any of these practices and regulations can lead to fraud, financial losses, and severe penalties. (15)


FHIR itself isn’t a security protocol and implementation of FHIR doesn’t require security protocols implementation. It is up to the implementers to ensure adequate security protocols are in place to safeguard healthcare data. Here are some of the mechanisms which can ensure healthcare information security: (16)


Encryption

Encrypting the information at the transport layer (TLS) of the internet using Hyper Text Transfer Protocol Secure (HTTPS) for secure transmission. This can prevent deliberate interception and tampering of medical record data between the two systems. (17)


Authorization and Authentication

Access control with the use of authentication and authorization protocols is described in SMART on FHIR implementation. OAuth is an open protocol that allows secure authorization in a simple and standard manner from web, mobile, and desktop applications. To authorize access, first, the subject needs to be identified which can be done by using an authentication protocol such as OpenID Connect. This authorization and authentication protocol could be implemented at either one or all of the client, server, or database/repository levels. Here's a guide ( [5] ) for SMART on FHIR authorization and app launch process.


Security Labels

Security labels are another means to control access. These tags can be embedded within the resources specifying access rules as appropriate by granting or rejecting access. A few examples are general confidentiality level (Low to Very restricted), the patient is a celebrity or a staff member, information is not to be shared with the patient, or with their family, the information relates to sensitive medical diagnoses (STD and mental illness). (16)


Provenance and Audits

These are some of the resources in FHIR that can be implemented to track who has accessed the system and what information was exchanged. Finally, and most importantly, a separate governance group must be created to ensure these security measures are utilized and implemented properly for the project.


Evaluations

Evaluations must be done to ensure the system is implemented the way it is intended. Implementers will need to evaluate the results on the patient-facing side in a test environment. The major validation requirement would be to make sure mappings are accurate by manual review of any automated implementations. Additionally, the security measures implemented above would need to be evaluated before going live.


Conclusion

In today’s digital age, patients must be provided with their information accurately and promptly. Providing this digitally makes it easier for patients to keep their health records safe and available as opposed to paper versions. Creating such a system would also make further interoperability with patient, provider-facing applications easier in the future.


References

1. HealthIT.gov 21st Century Cures Act [Available from: [6].

2. USCDI V3 [Available from : [7].

3. Benson T, Grieve G. Principles of FHIR. In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 79-102.

4. Ricardo CM, Urban S, Davis K. Databases illuminated, Chapter 12. Fourth edition. ed. Burlington, MA: Jones & Bartlett Learning; 2022.

5. Benson T, Grieve G. Implementing FHIRFast Healthcare Interoperability Resources (FHIR). In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 173-91.

6. Data models [Available from: [8].

7. LOINC guides [Available from: [9].

8. Benson T, Grieve G. LOINC. In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 325-38.

9. LOINC on FHIR [Available from: [10].

10. LOINC Risks [Available from: [11].

11. Resource Diagnostic Report [Available from: [12].

12. Resource Observation [Available from: [13].

13. Bloomfield RA, Jr., Polo-Wood F, Mandel JC, Mandl KD. Opening the Duke electronic health record to apps: Implementing SMART on FHIR. Int J Med Inform. 2017;99:1-10.

14. SMARTHEALTHIT [Available from: [14].

15. Ricardo CM, Urban S, Davis K. Databases illuminated, Chapter 8. Fourth edition. ed. Burlington, MA: Jones & Bartlett Learning; 2022.

16. Benson T, Grieve G. Security Security& Integrity in FHIRFast Healthcare Interoperability Resources (FHIR). In: Benson T, Grieve G, editors. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT. Cham: Springer International Publishing; 2021. p. 193-210.

17. Liu TJ, Lee HT, Wu F. Building an Electronic Medical Record System Exchanged in FHIR Format and Its Visual Presentation. Healthcare (Basel). 2023;11(17).


Submitted by (Ritchie Verma, MD)

--RitchieVerma (talk) 16:48, 1 May 2024 (UTC)

Retrieved from "http://www.clinfowiki.org/wiki/index.php?title=FHIR_Implementation_Guide&oldid=33661"