HL7 FHIR plus OAuth2 in a NHS trust
•Download as PPTX, PDF•
1 like•1,210 views
How a paperless NHS trust manages the document workflow simply and securely with HL7 FHIR an OAuth2. Also look at how FHIR/resource API solves information governance / INFOSEC issues. Slides from 2015 HL7 FHIR DevDays in Amsterdam
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to HL7 FHIR plus OAuth2 in a NHS trust
Similar to HL7 FHIR plus OAuth2 in a NHS trust (20)
Recently uploaded
Recently uploaded (20)
HL7 FHIR plus OAuth2 in a NHS trust
- 3. Confidentiality Data Protection 1998 Data Protection Principles Processed fairly and lawfully Processed for specified purposes Adequate, relevant and not excessive Accurate and kept up-to-date Not kept for longer than necessary Processed in accordance with the rights of data subjects Protected by appropriate security (practical and organisational) Not transferred outside the EEA without adequate protection
- 4. Patient Choices Consent/Dissent to share Sealing Sealing and Locking Consent/Dissent to store
- 5. Information Security (INFOSEC) Confidentiality Information must be secured against unauthorised modification Integrity Information must be safeguarded against unauthorised modification Availability Information must be accessible to authorised users at times when they require it.
- 7. Extract, Transform and Load
- 9. FHIR Mission
- 10. Resource API Document Repository TIE / API Router Laboratory Information System PAS / EPR NHS England (Spine, CP-IS, FGM, etc) GP and Community Record OAuth 2 FHIR
- 11. Trusted Applications Resource Owner Password Credentials Grant
- 12. Enterprise Integration everywhere TIE (API Router) EDMS PAS Dictation Vital Signs PAS Web Patient Identity Feed (HL7v2) Provide Documents (HL7 FHIR) Provide Documents (HL7 FHIR) Retrieve Document (HL7 FHIR) Retrieve Document (HL7 FHIR)Patient Demographic Query (SQL) Patient Demographic Query (HL7 FHIR) Document Registry Query (HL7 FHIR)
- 13. Resource Owner Password Credentials Grant Client App Auth Server Resource Server Access Token Request Access Token Response GET Patient – Resource Request Protected Response Oauth2 Resource
- 15. Document Sharing (Local) Cross Enterprise Document Registry (XDS +FHIR) GP Document Repository Social Services Dcoument Repository Acute Document Repositories Mental Health Doc Repository GP Document Repository GP Document Repository
- 16. Consent/Dissent to share Sealing Sealing and Locking Consent/Dissent to store Patient Consent Consultant Nurse GP Social Worker Health worker Role Community, Acute, Sexual Health, Child Services, Social Service, GP, Mental, etc Service
- 17. Authorisation Code Grant Flow Client App Auth Server Resource Server Access Token Request Access Token Response ‘GET CarePlan’ – Resource Request Protected Response Oauth2 Resource User (or Patient Consent) Authorisation Request Redirect for authorisation Login and consent Authorisation Code
- 18. Patient Consent
- 19. Stack
- 20. Any Questions Mayfield.g.kev@gmail.com +44 (0) 771 888 1774 Skype: kevingmayfield Twitter: KevinGMayfield www.mayfield-is.co.uk
Editor's Notes
- <Hello’s> This morning I’m going to over our two year journey with FHIR, how it is changing our architecture and especially our use of Oauth2 to secure
- First of all we will run through why are moving to FHIR, it’s not because it’s a new technology. We are using it because it solves problems, more specifically Information Governance Issues.
- Information Governance provides confidentiality, from a legal perspective this is driven by Data Protection Act 1998. The principles are shown here but I’m not going into detail of them.
- Let us first look at specific areas in particular the choices the patient has on contolling informaion. In England this is: Sealing - For example, suppose that John attends a genito-urinary medicine clinic. He is found to be suffering from syphilis. John asks for the diagnosis to be sealed. The next time he goes to the clinic, he sees a different doctor and that doctor is able to see the information (although she is informed that the syphilis diagnosis and the associated information is sealed). An appointment is made for John to see the ophthalmologist. The ophthalmologist looks on the computer for the history of diagnoses recorded for John. All of John's diagnoses are revealed apart from syphilis. An icon is displayed to show that some information has been withheld. Locking – Is stronger form of sealing and the ophthalmologist would not be aware it’s existence. http://systems.hscic.gov.uk/infogov/confidentiality/choices
- Confidential. Rules that limit access to information. Passwords, authentication Integrity. Information isn’t tampered with and trust worthy. Access controls. Availability – Reliable access to authorised people. Protecting against failure such as clustering.
- Having had brief look at information governance. Lets move onto the two common patterns for handling patient information
- In England this is a very common practice and is found from small organisations such as primary care groups to very large acute trusts. It’s prime use is statutory reporting e.g. GP Data. GP Data was a recent initiative to extract primary care data from GP systems for payments, reporting and research. This faced widespread criticism from GP’s, patients mostly around confidentiality, concerns of the intended use and the project is now under review. It is also a common method of feeding data warehouses and central repositories mainly especially in smaller organisations who tend to have little experience of integration – they will use tools they know. As ETL tends to be over night processes, these HIE tend to not show current information – the current information is not available
- This is a pattern many of us will be familiar with – messaging. Typical messaging used with a NHS Trust. Information is distributed to many recipients regardless of a legitimate relationship between the service/system and the patient. Still a valid pattern but has IG concerns, e.g. can’t carry sexual health encounters, can’t distribute addresses for children in protected care, etc. Also what happens if information is wrong. Say a patient diagnosed as an alcoholic and this has been distributed to many systems (in one case I am aware of the doctor thought the patient may be a alcholic, the ‘thought’ was lost. How does the patient correct or seal this information? This pattern is still valid, it solves a number of problems and we intend to carry on with it especially around ADT
- But we have many areas where we need other solutions and this is where FHIR comes
- One solution to these problems is the resource API. Promotes confidentiality by limit the distribution and instead provide api’s for the current information to be retrieved. Maintain the integrity by using access controls provided by OAuth2 which fits well with this pattern. Resource API can be easily clustered to aid availability and is directly accessing source systems returning current information. FHIR supports a resource API –this is one of the main reasons we began using it was chosen, we needed a resource API to help solve IG issues. We’ve had concerns about FHIR’s DSTU status but the pattern was correct and what do you use instead?
- Resource API + FHIR helps us with the availability of information but how do we go about securing the information.
- <Describe diagram – highlight HL7v2 stil being used.> Moving to resource API we have utlilised open source such as Apache Camel, ServiceMix and Tomcat to move polling (describe) and chatty (complex - describe) API’s from running across the network. We have now moved this nearer the source and effectively created microservices that produce FHIR. This change in topology removing transformation and gateways from the central TIE to many micro-services with centralised routing and BP, has proved robust and easier to maintain butit has increased the security overhead. This is where OAuth2 comes in.
- Each ESB or TIE is protected by Oauth2 or more specifically a OAuth2 resource server. To access the resource you need an access token. <describe diagram>
- The resource owner grant works for trusted applications but going back to the original requirement we need to finer level of controls on top of the resources. The availability of a resource will depend on who is asking for it, what the data is and what controls the patient has placed on it.
- I’m not going to go into details on web apps accessing resources but instead concentrate on an example of document sharing we used with a Health Information Exchange in Edinburgh, Scotland. This was a community initiative to share data between acute, community and social services. The documents being shared included patient assessments and referrals. This is very similar to normal IHE XDS pattern.
- Although it was very easy to quickly find an appropriate pattern (xds) and select the api. It was far harder to get the information governance in place. Citizens had address that were confidential – battered wives, kids taken into care. Concerns information shared with social services would be made available to other council/governent departments. Patients may release information to NHS that didn’t want shared with Social services. <Run through slide>
- <run through diagram> The main candidate for authentication is the existing NHS Spine Directory Services which provides authentication services via smartcard and a LDAP database. This provides a database of users, their roles and what specialty they work in. So we can now use more complex filter to protect roles, we can protect a a resource based what type of information is being protected and restrict access based a users role and their specialty – so we can ensure only practitioners in sexual health can access information about sexual health. However this leaves patients consent/dissent to deal with.
- We’ve still not covered Patient Consent. In Scotland we collected consent as part of the referral process but one idea is to use the same authorisation grant and allow the patient to consent or dissent to sharing via Patient Portals. In the example shown here, the ‘Jorvik NHS trust’ is request access to data stored on the popular cycling/running app Strava or the more familiar facebook request for permission. In practice the authorisations would be down to local design but could include consents to: share data with NHS trusts, social services, NHS England Summary Care and GP Data.
- We have used numerous tools to implement OAuth2. The stack is primarily open source and Java based. Using spring security allows us to customize and adopt the rules without disturbing the other layers too much.