Achieving RBAC on RESTful APIs for Mobile Apps using FHIR

Transcription

1 2017 5th IEEE International Conference on Mobile Cloud Computing, Services, and Engineering Achieving RBAC on RESTful APIs for Mobile Apps using FHIR Yaira K. Rivera Sánchez, Steven A. Demurjian, & Mohammed S. Baihan Department of Computer Science & Engineering University of Connecticut Storrs, CT, USA {yaira.rivera, steven.demurjian, Abstract Health Information Exchange (HIE) provides a more complete health record of an individual that improves patient care with relevant data gathered from multiple health information technology (HIT) systems. In support of HIE, the Health Level Seven (HL7) XML standard was developed to manage, exchange, integrate, and retrieve electronic health information. In 2011, HL7 began drafting a next-generation standard, Fast Healthcare Interoperable Resources (FHIR), to facilitate the development and interaction of mobile health (mhealth) apps, HIT data sharing, and common format for information modeling. FHIR is based on RESTful APIs and supported by a FHIR server infrastructure that facilitates the exchange in a cloud computing setting. FHIR while possessing a security specification, has yet to define and identify actual security mechanisms for secure data exchange via RESTful API calls. In this paper, we incorporate role-based access control (RBAC) into FHIR to support the ability to control access of who can call which services of FHIR RESTful APIs that manage sensitive healthcare data. The work is demonstrated utilizing a mhealth application that communicates with the OpenEMR electronic health record via the HAPI FHIR server. Keywords- access control; data management; Fast Interoperable Healthcare Resources (FHIR); healthcare systems; interoperability; mobile applications; role-based access control (RBAC) I. INTRODUCTION The transition from paper-based to electronic health records (EHRs) has greatly increased in the past decade with eight out of ten physicians in the U.S. utilizing EHRs in their practices [1]. Despite this progress, there is still a need for a significant next step to allow patients and medical providers to easily access healthcare data that is distributed across multiple EHRs and other health information technology (HIT) systems. To support these actions, health information exchange (HIE) for the interoperation across sources has the potential to reduce healthcare data expenses where healthcare institutions could save up to $77.8B in the U.S. [2]. In addition, the Office of the National Coordinator (ONC) issued a report [3] in 2015 on certification rules for EHRs that has required that HIT vendors develop RESTful APIs for EHRs and other systems so that patients and medical providers using mobile health (mhealth) applications (apps) can easily access their healthcare data from multiple sources. In order to provide the sharing and exchange of information, healthcare standards have been developed including: Health Level Seven (HL7) v3 [4], which is a standard to manage, exchange, integrate, and retrieve electronic health information; and, the Digital Imaging and Communications in Medicine [5] standard for distributing and viewing medical images. In 2011, HL7 introduced the first draft of the Fast Healthcare Interoperability Resources (FHIR) specification designed to enable interoperability and integration with the newest and adopted technologies by the industry with a particular focus on making healthcare data in different EHRs/HIT systems easily available to mhealth apps via RESTful APIs in the cloud. FHIR has a set of security requirements [6] that identifies the major topics (communications security, authentication, authorization, access control, auditing, digital signatures, etc.). However, FHIR lacks concrete mechanisms that would be capable of controlling access to the services of RESTful APIs that contain sensitive healthcare data stored in the cloud. Access control mechanisms are regularly utilized to secure highly sensitive data in order to determine which information each user can access/store in a particular system, with the proviso that disclosing the wrong information could lead to serious consequences [7]. The three dominant access control models [8] to achieve this are: role-based access control (RBAC); discretionary access control (DAC); and, mandatory access control (MAC). Our previous work focused on an initial effort on authentication requirements for mobile apps [9] that was expanded to define an approach for rolebased access control (RBAC) for mobile computing [10]. The work in this paper builds off of [9,10] to incorporate RBAC into the FHIR standard and its infrastructure, to allow a mhealth app that is FHIR-compliant to exchange healthcare data that is in the cloud with multiple EHRs/HIT systems. This will be achieved by defining on a role-by-role basis, the subset of the FHIR RESTful API services that are available to users of a mhealth app, to intercept calls that are not allowed, thereby prohibiting access to the sensitive healthcare data associated with those calls. We incorporate RBAC into the FHIR architecture and demonstrate its actual inclusion via the HAPI FHIR reference implementation [11] that includes the HAPI FHIR library and open-source implementation of the FHIR specification in Java. The HAPI FHIR reference library contains several features that we take advantage of in order to intercept the FHIR server to allow the service calls that the mhealth app makes against the RESTful API service calls to be checked against defined RBAC policies. The remainder of the paper has four sections. Section II reviews background and related work. Section III presents a set of proposed modifications to incorporate RBAC into the FHIR specification and its realization within the HAPI FHIR reference implementation. To demonstrate the inclusion and realization of RBAC for a mhealth app within HAPI FHIR, /17 $ IEEE DOI /MobileCloud

2 Section IV provides an implementation of the proposed approach by using the Connecticut Concussion Tracker (CT 2 ) mhealth app and the OpenEMR HIT system [12]. Finally, Section V concludes the paper and discusses ongoing work. II. BACKGROUND AND RELATED WORK In this section, we review background and related work. For background, we discuss: role-based access control; and, FHIR and its Resources, RESTful API, and the HAPI FHIR reference implementation library. For related work, we examine and contrast to our work three existing approaches [13, 14, 15] with proposed security mechanisms for FHIR. Access control is a security process and mechanism that allows user requests to be granted or denied against the resources (objects) of a system or app, while authorization is the process that is specifically associated with allowing or denying access to a resource (object). The security specification of FHIR [6] requires that an implementation of FHIR embraces communications security, authentication, authorization, access control, auditing, digital signatures, etc., for usage in real-world situations. The FHIR security specification [6] also identifies two approaches that can be applied within the authorization layer of FHIR, namely, rolebased access control (RBAC) [16] and attribute-based access control (ABAC) [17]. In RBAC, users are assigned roles and each role contains different permissions, which contain the policies of which operations and objects a user with a particular role can have access to. ABAC, a context-aware approach, considers the user s responsibilities and places users in groups/roles based on attributes. For the purposes of this paper, we focus on applying RBAC to FHIR resources, to authorize which services of the RESTful APIs are available on a role-by-role basis for users of a mhealth app. FHIR is a standards framework created by HL7 with the intention of providing easier and quicker implementation of interoperability in healthcare systems to facilitate access of mhealth apps to healthcare data in the cloud as stored in multiple EHRs/HIT systems. One of the main goals of FHIR is to represent the entities and procedures in healthcare as resources [18]. These are classified into six sections which represent pieces of data (e.g., Patient, Condition) such as the entities involved in the care process (e.g., patients demographics) and the healthcare process itself (e.g., management of a patient s appointment). There are approximately ninety resources that can be utilized to map data from a healthcare system and the implementers of these resources claim that more resources will be added in a future [19]. The available resources can be accessed through the means of a RESTful API, which allows to connect healthcare interfaces with data sources that exist in the cloud. Different from SOAP (Simple Object Access Protocol) [20], which has been the dominant approach to manage web services interfaces over the past years and it is utilized in HL7 v2, RESTful APIs are easier to understand and to implement as they rely on HTTP and on Create, Read, Update, and Delete (CRUD) operations to develop services. One popular open-source library that implements FHIR specification is the HAPI FHIR reference implementation [11]. HAPI FHIR was developed in the Java programming language and offers the features of FHIR in addition to other features such as the ability to intercept the server (by using Java servlets [21]) that processes the user s requests. This intercepting feature is critical to support our interception of RESTful API calls in order to check RBAC security permissions to prevent unauthorized access to services that have not been assigned to a given role for a mhealth app. The FHIR standard is in a drafting phase, as the specification evolves over time. Nevertheless, there are a number of efforts that have appeared to address the way that security in FHIR could be realized. The first effort [13] applied FHIR to the AidIT mhealth app for patients, doctors, and pharmacists in order to demonstrate the way that a mhealth app can be integrated with the FHIR server side. The AidIT app can be utilized by users who have different privileges, uses QR codes to secure the data, and includes an RBAC mechanism to apply security policies to CRUD actions. The access control model is enforced within the user interface of the mobile app by only showing the components (buttons and tabs) that can be accessed according to a user s role. This approach does not enforce access control via FHIR and the RESTful API services, but focuses on programmatic changes to the AidIT mhealth app making reuse of the approach problematic for other mobile apps. Our proposed RBAC approach assigns RESTful based API services by role realized within the library utilized to implement FHIR. As a result, our approach is applicable to any mhealth app accessing RESTful API FHIR services to be controlled by RBAC, and is reusable without needing to modify app code. The second effort [14] applies FHIR to a health monitoring system of vital signs (blood pressure, blood sugar, etc.) for patients in cardiac rehab and for elderly with chronic diseases. The effort collected information using the Observation FHIR resource for 68 patients and nearly 2000 data points. However, despite the work acknowledging the need to support security, this was a subject for future work. The third approach SecFHIR [15] presented a security specification model on FHIR resources represented using XML or JSON schemas. The work on SecFHIR defined permissions on schemas, which implicitly specify the permissions on the corresponding XML instances; this is contrary to the ONC [3] effort to have RESTful APIs for healthcare data availability. Our focus on applying RBAC at the role/restful API level means that our policies are applicable regardless of the actual data format. Our work also does not need to add permission tags that would impact the FHIR resource standard schemas for XML and JSON. III. ROLE-BASED ACCESS CONTROL IN FHIR This section presents a set of proposed modifications to incorporate RBAC into the FHIR specification and its realization, in a general sense, within the HAPI FHIR reference implementation in three parts. In Section III.A, the 140

3 FHIR security specification is briefly reviewed to describe its current status and the way that our RBAC approach can be incorporated to control access to RESTful API services. Section III.B reviews the HAPI FHIR reference implementation capabilities with a focus on the intercepting process that can support our RBAC approach. Section III.C explains the integration of the concepts from Section III.A and Section III.B via the FHIR HAPI library that incorporates RBAC into our RBAC Server Interceptor. A. The FHIR Security Specification The FHIR security specification does not yet include explicit security capabilities, but does deliver different exchange protocols and models that could be utilized with security policies created by an organization [6]. To handle security, FHIR suggests several points including: securing data exchange with TLS/SSL (e.g., HTTPs); authenticating users with an authentication method (e.g., OAuth); and utilizing digital signatures. In addition, FHIR defines security labels to support access control management. The security labels were done with the purpose of restricting access on resources based on security policies established by security administrators of the data that is being exchanged. Nevertheless, there is very little documentation on the way that role-based access control policies could be both defined and enforced through the means of these labels. In addition of suggesting security labels, the FHIR security specification provides a notion of where security needs to be placed in the logical layout of a system in order to handle users, user authentication, and user authorization. The FHIR security specification also assumes that a security system exists and that is positioned before or after the FHIR API [6]. Fig. 1 shows three possible scenarios on the locations where a security system can be deployed on the logical layout of a system. Basically the layout is composed of clients, of a client (mhealth) app, of data sources (EHRs and other HIT systems), and of FHIR layers. The first scenario applies security mechanisms between two layers of FHIR where the first layer would be a security system. The second scenario places security on the client application. Lastly, the third scenario places security server-side [6]. For the purposes of this paper we focus on applying RBAC by using a similar idea to the one exposed in the first scenario. In the rest of the paper, we make two assumptions: a mobile app needs to obtain information from one or more data sources (e.g., EHRs or HITs) which are connected by a cloud server; and, a cloud server that connects the mobile app with the data sources is a FHIR sharing infrastructure. B. The HAPI FHIR Server Interceptors Our proposed approach consists on incorporating RBAC into FHIR at specification and implementation levels so that all of the clients and HITs/EHRs that utilize the HAPI FHIR library to implement the FHIR specification can take advantage of the added access control capabilities. Currently, two popular third party FHIR reference implementations are available that allow implementers to adopt the FHIR specification in practice the HAPI FHIR reference implementation for Java [11] and the Swift FHIR reference implementation for ios/os X [22]. Note that there are also many other open source reference implementations [23]. We chose HAPI FHIR since there are many samples of creating FHIR servers and clients in a quick manner and its library contains the ability to intercept the FHIR server before a request is processed and after the request has been processed in order to add access control to the user s request and/or to the server s response (see Section II). Note that even though HAPI FHIR offers this intercepting feature, the developer is responsible of creating the security model, policies, and enforcement process realized via the interceptors. Specifically, we demonstrate the way that the interceptor class can be generalized to reuse our RBAC approach for intercepting API calls with other cloud frameworks. HAPI FHIR offers several server interceptor functions [24] that allow developers to perform actions on the user s request before it is executed and after its execution (before the response is delivered to the user). The main interceptors the library provides are: the incomingrequestpreprocessed interceptor which can be called before the request is processed; the incomingrequestpostprocessed interceptor which can be called once the request is classified (URL and request headers are examined in order to know this); the incomingrequestprehandled interceptor which can be called once the request has been handled; and, the outgoingresponse interceptor, which can be called after the operation is handled but before the response is returned. In addition to these interceptor functions, HAPI FHIR developers are in the process of implementing authentication and authorization interceptors [25]. The authorization interceptor attempts to apply security to FHIR by creating a set of rules via rule-based access control within the function and utilize if/else statements in order to whitelist/blacklist requests. In our case, instead of utilizing rule-based access control, our approach involves the use of RBAC. Further, instead of modifying the code of the intercepting function every time we want to add/modify a permission to/in the policy (e.g., change a role or a permission on a role), we implement an RBAC interceptor function one time that consults permission and privilege definitions by role in a database. When changes to the security policies stored in a repository are made, the RBAC interceptor function will continue to work to check intercepted RESTful API calls. Fig. 1. Security system placement in deployment architecture [6]. 141

4 C. Proposed RBAC Server Interceptor This section introduces the proposed RBAC Server Interceptor Architecture in Fig. 2 that is used to evaluate which FHIR resources users are allowed to access by role via the corresponding FHIR RESTful API. When the client makes a request using the client application, this request will be handled by a FHIR server. The FHIR server is implemented with the HAPI FHIR reference implementation library with programmatic access to the server interceptor class. Fig. 3 has pseudocode of our RBAC approach as implemented within the incomingrequestpostprocessed function available in HAPI FHIR; this is essentially the RBAC Interceptor function discussed in Section III.B. Fig. 3 rewrites HAPI s incomingrequestpostprocessed interceptor function to obtain details of the request (e.g., HTTP method used) and the resource that is being evaluated before an object can be obtained. In the function, we retrieve the authorization header passed with the request, which contains an access token that holds the user s id as well as his/her role and, we verify this token by calling an API service (line 3 of Fig. 3). If the user passes the role verification (the API service returns a value greater than 0), then the access control policies for the requested resource are retrieved with the use of an API service (line 6 of Fig. 3); otherwise, the function blocks the request from executing and returns an error message. The API service implemented to retrieve the security policies from the intercepting function consists of the following parameters: the HTTP method of the request (e.g., POST, GET, PUT, DELETE); the resource the user is trying to access; and, the role of the user (line 7 of Fig. 3). If the role of the user has access to the requested resource and the specific authorized CRUD service, the service will return true and the request will continue. Otherwise, the process will come to an end and the intercepting function will return an error message. To manage which resources a specific role can access we need to have an access control policy stored in a repository or database which we can then retrieve from the intercepting function to either block or allow the request. Basically, once the user s role has been verified we can access the specific permission we want to evaluate through the means of an API service as stated in the previous paragraph. The database would hold the roles for each user of each mhealth app along with the permissions for each role to each HIT system supported with the HAPI FHIR server; specifically, to track which services of which FHIR RESTful APIs for each HIT are authorized by role to a user of a particular mhealth app. Note that we are not considering the primary key as an essential field for our security policy since it is only used for indexing purposes. With that in mind the role_id field contains the available role ids in a system, the http_method field contains the HTTP methods available in the system (e.g., GET, POST), the resource_name field contains the resources that are available in the system, and the permission field establishes whether a user with a particular role has access to the HTTP method he/she requested of a specific resource. Sample access control policies will be provided in Section IV, Table 1. Fig. 2. Proposed RBAC Server Interceptor Architecture. Fig. 3. Proposed Access Control Approach within the incomingrequestpostprocessed function. IV. IMPLEMENTATION To evaluate the incorporation of RBAC into FHIR, the Connecticut Concussion Tracker (CT 2 ) mhealth app, database, and server are connected to an instance of OpenEMR [12] via HAPI FHIR. CT 2 is a collaboration between the Departments of Physiology and Neurobiology, and Computer Science & Engineering at the University of Connecticut and Schools of Nursing and Medicine in support of a new law passed in the state of Connecticut to track concussions of kids between ages 7 to age 19 in public schools (CT Law HB6722 [26]). The CT 2 app is for Android and ios devices and uses a FHIR server to manage its data, which is stored in an instance of OpenEMR [12] (accessed through a FHIR server as well and located in a cloud server). The CT 2 mhealth app utilizes the following four FHIR resources in order to create, read, and update subsets of the data (delete is not allowed in this app): Patient to track demographics and other basic information of patients (students that suffer concussions); Condition to track a medical condition, in our case a concussion; Observation to track symptoms of patients (students); and CarePlan to track the planned treatment for a condition (concussion). To begin, Fig. 4 shows the mapping of resources and the location of the RBAC server interceptor function within the FHIR instance of the CT 2 mhealth app. Note that each of the FHIR Resources (Patient, Condition, etc.) for both CT 2 and OpenEMR have a FHIR RESTful API with CRU services (no delete). We incorporate the RBAC server interceptor function as a security layer before the requested resource attempts to retrieve/insert/update data from the OpenEMR system, similar to the first option in Fig. 1 where the first FHIR layer consisted of a security layer. If the requested resource successfully passes the security checks in the server interceptor function, then the HAPI FHIR controller class of CT 2 will receive the request and send it to the appropriate OpenEMR FHIR resource class along with any parameters by using another instance of FHIR. In this case, both of our 142

5 FHIR instances were implemented using the HAPI FHIR library. Specifically, FHIR requires that information in the CT 2 database is mapped to/from FHIR resources and information in the OpenEMR repository is mapped to/from FHIR resources and, exchanged through shared resources via the CRUD FHIR APIs defined for each resource for both CT 2 and OpenEMR FHIR APIs. interceptor function is registered in the RestfulServer instance of the FHIR server, namely, on the CT 2 FHIR server, by making reference to the class by either calling registerinterceptor or setinterceptors. Fig. 4. CT2-OpenEMR FHIR Mapping. To determine the type of action a user of CT 2 can perform on these FHIR resources, we defined four roles: Nurse role which has access to all of the resources (CRU for CT 2 FHIR RESTful API) to manage a student s concussion incident from its occurrence to its resolution; Athletic Trainer (AT) role which is allowed to do a limited preliminary assessment if a concussion incident occurs at the event; Coach role which can report a concussion incident at an athletic event with very limited information on the student; and, Parent role which can report a concussion incident on his/her child while attending the athletic event or track the current status of his/her children that have ongoing concussions. Table 1 defines the permissions for CRU for all resources for all four roles. These policies are stored in a security policy database and will be accessed through the use of the RBAC server interceptor function incomingrequestpostprocessed which is part of the server interceptor class the HAPI FHIR library offers. Notice that in Table 1, a user with a Nurse role has access to all CRU services of all resources; at the other extreme, a Coach role is limited to reporting and reading the basic information on the concussion by having only access to CR for the Patient and Condition resources. The creation of the RBAC permissions to FHIR services by role in Table 1 allows fine-grained control of the FHIR RESTful APIs for the four Resources utilized by the CT 2 mhealth app. TABLE I. CRUD PERMISSIONS OF CT 2 FHIR RESOURCES. Resource/Role Athletic Trainer Coach Nurse Parent Patient C, R C, R C, R, U C, R, U Condition C, R C, R C, R, U C, R Observation C, R R C, R, U C, R CarePlan R R C, R, U R The pseudo code as given in Fig. 3 is transitioned to the RBAC server interceptor function given in Fig. 5: incomingrequestpostprocessed. This function is included within a class that extends the InterceptorAdapter class, which is part of the server interceptor feature HAPI FHIR offers. In addition, in order for the server to recognize that we want to utilize the intercepting class, the RBAC server Fig. 5. Contents of the incomingrequestpostprocessed function in the CT 2 FHIR Server. The CT 2 mhealth app was tested with two accounts: one for a user assigned the role of Nurse and the other for a user assigned the role of Coach. In the test, both the Nurse and the Coach users attempt to utilize the CT 2 mhealth app to update information on a student s concussion case (the UPDATE/PUT operation). However, as noted in Table 1, while Nurse has U access to a Patient resource, Coach does not. As a result, the Coach user s request fails since the permission U is not present in Table 1. Therefore, the incomingrequestpostprocessed function located within the CT 2 FHIR server java code will abort the execution of the request and return an error message to inform the user that he/she does not have permission to the requested resource as shown in the top image of Fig. 6. In the case of a user with a Nurse role, Table 1 shows that the role has U permission on the Patient resource meaning it has permission to update a patient, therefore, the request is performed successfully as shown in the bottom image of Fig. 6. Another situation that is also supported in the RBAC server interceptor function is if the user has managed to tamper his/her role in order to obtain more privileges. This action will be identified when the access token sent on the header is verified and will block any further execution of the request and send an error message to the user telling him/her that the user verification failed as shown in Fig. 7. Note that the RBAC server interceptor function can return error messages as either JSON or XML format (which are the formats that are available in FHIR to return the client a response). We utilized JSON since this is the format that the CT 2 mhealth app has for handling the user requests and responses. In addition, the requests shown on Figs. 6 and 7 were made with Postman [28] instead of doing these directly with the CT 2 mhealth app in order to present a clear view of the response the requests can have in different scenarios. V. CONCLUSION AND ONGOING WORK This paper has proposed a novel approach to support 143

6 RBAC security policies for mobile computing in a cloud setting incorporated into FHIR to facilitate information exchange between a mhealth app and multiple EHRs/HIT systems. The FHIR infrastructure in Section II defined Resources with CRUD RESTful APIs as a common format for exchange in the cloud. RBAC in Section III was defined and enforced for the FHIR RESTful API of each Resource, allowing a given user/role combination to be authorized to specific CRUD services of each Resource. The RBAC as defined for FHIR was then incorporated into an actual reference implementation of the FHIR specification utilizing the HAPI FHIR library in Section IV with the CT 2 mhealth app interacting with OpenEMR via FHIR. Our work provided an RBAC server interceptor that realized and enforced security on FHIR RESTful API services allowing real-time checks to determine if a user has permission to invoke a FHIR RESTful API service on a resource through the means of the server interceptor feature the HAPI FHIR library has. Fig. 6. JSON Response Messages from Interceptor. Fig. 7. JSON Response Disallowed Request. In terms of ongoing work, we are exploring the inclusion of MAC and DAC into the FHIR specification as realized in HAPI FHIR. To support this effort, we are clarifying the way that a user s identifier and role (and clearance level) can be generated and stored in an access token (e.g., JSON Web Token [28]) that is passed through the header of a request. In addition, we plan to test our approach with a mhealth app that obtains data from multiple data sources, since the CT 2 app only connects to one data source. Finally, we are exploring the generalization of our intercepting approach with HAPI FHIR in order to obtain a solution that can be utilized in other apps that implement FHIR. REFERENCES [1] D. Heisey-Grove and V. Patel, Any, certified, and basic: Quantifying Physician EHR adoption through 2014, Sep Retrieved from ified_vs_basic.pdf. [2] J. Walker, E. Pan, D. Johnston, J. Adler-Milstein, D.W. Bates, and B. Middleton, The Value of Health Care Information Exchange and Interoperability, Health Affairs, 24(2), pp , [3] Health and Human Services Department, 2015 Edition Health Information Technology Certification Criteria, 2015 Edition Base Electronic Health Record Definition, and ONC Health IT Certification Program Modifications, Mar Retrieved from [4] Health Level Seven International, Retrieved from d=185. [5] DICOM, Digital imaging and communications in medicine, Retrieved from [6] FHIR, FHIR security, Sep Retrieved from [7] T.C. Rindfleisch, Privacy, information technology, and health care, Communications of the ACM, 40(8), pp , [8] R.S. Sandhu and P. Samarati, Access Control: Principles and Practice, IEEE Communications Magazine, 32(9), pp , [9] Y.K. Rivera Sánchez and S.A. Demurjian, Chapter 6: User Authentication Requirements for Mobile Computing, Handbook of Research on Innovations in Access Control and Management, IGI Global, [10] Y. K. Rivera Sánchez, S. A. Demurjian, J. Conover, T. Agresta, X. Shao, and M. Diamond, Chapter 6: An Approach for Role-Based Access Control in Mobile Applications, (S. Mukherja, Ed.), IGI Global, [11] HAPI FHIR, HAPI, Retrieved from [12] OpenEMR, Retrieved from [13] G.C. Lamprinakos, A.S. Mousas, A.P. Kapsalis, D.I. Kaklamani, I.S. Venieris, A.D. Boufis et al., Using FHIR to develop a healthcare mobile application, IEEE, pp , [14] B. Franz, A, Schuler, O. Krauss, Applying FHIR in an integrated health monitoring system, EJBI 2015, 11(2), pp , Jan [15] A.M. Altamimi, SecFHIR: A security specification model for Fast Healthcare Interoperability Resources, International Journal of Advanced Computer Science and Applications (ijacsa), 7(6), [16] D. Ferraiolo and R. Kuhn, Role-Based Access Control, Proc. of the NIST-NSA National Computer Security Conf., pp , [17] E. Coyne and T. Weil, ABAC and RBAC: scalable, flexible, and auditable access management, IT Prof., vol. 15(3), pp , [18] FHIR DSTU2, Guide to resources, Retrieved from [19] FHIR Resources, Resource Index, Retrieved from [20] W3C, Latest SOAP versions, Retrieved from [21] Java, Java Servlet Technology, Retrieved from [22] SMART on FHIR, Swift-SMART, Retrieved from [23] HL7 International, Open source FHIR implementations, Sept Retrieved from ons. [24] HAPI FHIR, Server Interceptors, Retrieved from [25] HAPI FHIR, Server Security, Retrieved from [26] Connecticut General Assembly, Substitute for raised H.B. No. 6722, Retrieved from ftp://ftp.cga.ct.gov/2015/cbs/h/hb-6722.htm. [27] Postman, Postman, Retrieved from [28] JWT, Introduction to JSON Web Tokens, Retrieved from 144