FEATURE MEDICAL ELECTRONICS
interoperability requirements mandated by governments. In NHS Identity deployment patterns
MEDICALLY SAFE AND IAM SOUND
Johann Nallathamby, associate director - solutions architect and Sherene Mahanama, senior technical writer at WSO2 discuss medical security
T
he ongoing COVID-19 pandemic has placed healthcare systems and their
efficiency (both operational and technological) under greater scrutiny. The healthcare industry has some of the most valuable, high-priced information sold on the dark web. Since they are a prime target for cybercriminals, it is vital for healthcare organisation to use a strong and secure Identity and Access Management (IAM) system to protect this information, while also ensuring that this extra security does not hinder the time-sensitive nature of healthcare work. Health data requires a high level of
security, however, it is tedious for healthcare professionals to constantly go through 2–3 levels of proving their identity when they barely have the time to do it once. Adaptive authentication can be
configured to only prompt extra steps of authentication when the authentication is abnormal in some way (e.g., authorising a high risk medicine, logging in from a different location/device etc.) Login analytics can be used to gain
insights into potential security risks and configure risk-based adaptive authentication. For example, if a doctor logs in from within the hospital network, this might require only one factor of authentication whereas a doctor logging in from home might require two-factor authentication. The NHS identity federation service
supports OpenId Connect, SAML or WS- Federation Federated Identity. Using one of these standards, WSO2 Identity Server can federate user accounts of patients/doctors over to the local system.
FINE-GRAINED ENTITLEMENTS One of the primary reasons for healthcare vendors and hospitals to require a good, stable IAM solution is to
18 SEPTEMBER 2020 | ELECTRONICS
authorise users securely according to the different levels of access they require. A pure role-based access control (RBAC) model will usually not be scalable in a health institution considering the different types of roles and specialisations in each of those roles. Instead, we could use permissions-
based-access control to assign permissions to roles on a more granular level by defining exactly which actions are allowed for a particular resource depending on the role. However, most practical real world
scenarios in the health industry would have more complex requirements and may require authorising access to certain resources based on attributes such as time of access, assigned patient ID, location, etc., in addition to the roles/permissions. Therefore, usually the most appropriate
form of access control would be to use a fine-grained, attribute-based authorisation policy language like XACML to define these complex and detailed authorisation rules. WSO2’s Identity Server can be used as a XACML engine to securely handle authorisation rules and access control.
API SECURITY APIs and microservices are used to collect and update patient data efficiently and securely. Healthcare APIs are an essential part of centralised healthcare management. Using APIs, hospitals and medical offices can share data within local systems in the UK to gain quick access to patient information, reduce errors, and improve overall efficiency. The WSO2 Healthcare Integration
Platform is built on top of WS02’s, open- source integration platform which allows you to quickly transform your data and expose secure APIs to meet
5 and 6, the user identity is sent from the NHS system to the local service provider to authenticate the user but the authorisation rules are handled by the local system. WSO2 Identity Server uses OAuth2 and can support the token exchange from NHS services to the local system and from the local system to NHS. Using WSO2 as the authorisation server for the local system, enables complex authorisation rules/policies, application of security to verify the API calls, and throttling to regulate the number of authentication calls. Furthermore, all six of the NHS
Identity deployment patterns highlight token exchange with a local/regional authorisation server. WSO2 Identity Server can also play the role of the local/regional server to accept incoming token requests in an API Manager ecosystem.
PROGRESSIVE PATIENT PROFILING Treating the healthcare platform as a CIAM project (Customer Identity and Access Management) can be a good approach to gain insights and a 360 view of a patient's activities. APIs can help towards providing
better patient care by capturing every part of the patient’s journey in that hospital. A patient may enter the hospital for a simple appointment that later escalates into multiple tests and scans, medications, surgery, post-care appointments, etc. With standardisation of APIs across all these services, the medical industry or at least hospitals in the UK, can avoid all this data being isolated among different, disconnected data silos and instead, use all of it to get a full and detailed collection of the patient’s healthcare story. A unified view of a collection of
patient information that is this big can be used to help profile or categorise patients. This is helpful in order to improve patient service in a variety of ways including alerting them when a doctor they were trying to channel is available or to do targeted marketing and promotions for patients depending on their interests. IAM solutions can provide ‘user
managed access’ mechanisms to enable this level of controlled data sharing between patients and healthcare providers.
WSO2
https://wso2.com
/ ELECTRONICS
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46
