FHIR Developer Days 2015. Study on db implementations for FHIR server
4 likes1,491 views
Presentation describes different approaches for implementing database for FHIR server, that were considered during implementation of Nortal National Healthcare System (NHS) for Lithuania.
![#3 PostgreSQL JSONB query examples 11
select id from fhir.patient
where content @> '{"name":[{"use":"official", "family":[”XXX"]}]}'
select c.id
from practitioner p
inner join condition c on
c.content -> 'asserter' ->> 'reference' = p.id
where p.content ->> 'name' ~ '"family":[ []*”XXX"*[ ]]'](https://image.slidesharecdn.com/fhirdevdays2015-151119110200-lva1-app6891/85/FHIR-Developer-Days-2015-Study-on-db-implementations-for-FHIR-server-11-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to FHIR Developer Days 2015. Study on db implementations for FHIR server (20)
Ad
Recently uploaded (20)
![[gbgcpp] Let's get comfortable with concepts](https://cdn.slidesharecdn.com/ss_thumbnails/dimitris-platis-gbgcpp-concepts-250508080200-9d7e1e91-thumbnail.jpg?width=560&fit=bounds)
FHIR Developer Days 2015. Study on db implementations for FHIR server
- 1. Nortal NHS in Lithuania - study on DB implementations for FHIR server Igor Bossenko, Jan Jasinski Nortal 19.11.2015
- 2. • Start: 2013-12 • LIVE: 2015-09 LT NHS project Develop standard and platform for health information exchange. Centralize health-related classifiers and registries. Gather medical information from Healthcare Providers Provide access to health related information for: • Patients; • Health-care providers; • Covernment.
- 3. Architecture FHIR DSTU1 REST + Documents Conformance: yes Profiles: no Security: OAuth + VPN Server: Java + OSGI Integration: Fuse ESB Database: Oracle 11
- 4. #1 Table per resource or datatype 4
- 5. #1 Query examples 5 Select * from Condition where Encounter_ID = 123; Select * from Human_Name_Part where Name_Part_Code = ‘family’ and value = ‘XXX’;
- 6. #1 Table per resource or datatype 6 • Pros Classical RDBS solution Easy to understand for non-FHIR people Suitable with the most BI tools Good response time Ability to optimize searches Work on every database • Cons DB structure too ugly Too static, does not support new resources or profiles Any resource extension need additional programming Searches are hardcoded, no ability to add new search parameters dynamically
- 7. #2 Resource store + custom index 7
- 8. #2 Query examples 8 select * from idx_string t1 inner join idx.idx_Reference ref1 on ref1.resource_type='Encounter' and ref1.ref_resource_type='Patient’ and ref1.search_param='patient' and ref1.ref_rid = t1.rid where t1.search_param='family' and t1.text_value=’XXX' and t1.resource_type='Patient’ select key from idx_string s where s.resource_type='Patient' and s.text_value like '%XXX%'
- 9. #2 Resource store + custom index 9 • Pros Works on every database Flexible Easy to understand Easy to develop • Cons Requires additional space for custom index tables and DB indexes for custom index tables Does not cover searches on data outside from index (custom searches in JSON/XML content) Not scalable
- 10. #3 Non-SQL + partitioning + JSON/XML index 10
- 11. #3 PostgreSQL JSONB query examples 11 select id from fhir.patient where content @> '{"name":[{"use":"official", "family":[”XXX"]}]}' select c.id from practitioner p inner join condition c on c.content -> 'asserter' ->> 'reference' = p.id where p.content ->> 'name' ~ '"family":[ []*”XXX"*[ ]]'
- 12. #3 Non-SQL + partitioning + JSON/XML index 12 • Pros Very flexible Good response time • Cons Implementation depends on database
- 13. #4 BigData 13 • Apache HBase • Apache Phoenix • Custom indexes on JSON content for simple queries • Work In Progress on complex queries
- 14. #4 BigData 14 • Pros Very scalable Index-based search is very quick • Cons Environment installation is more complex Too new (for me) Currently we don’t have solution for complex queries (WIP)
- 15. Test data 15 Resource Rows Practitioner 23 187 Patient 1 625 084 Encounter 11 125 528 Condition 17 375 336 DiagnosticReport 31 719 078
- 16. Response times (avg) 16 Test #1 Table per resource #2 Custom index #3 JSON index + partitioning #4 BigData Get patient record by resource Id 20 ms 100 ms 20 ms 20 ms Find patients by exact name (=‘FAMILY’) 35 ms 35 ms 120 ms 30 ms Find patients by name part (like '%FAMILY%') 150 ms 34000 ms 70 ms WIP Find patients by exact system and identifier 35 ms 50 ms 115 ms 30 ms Find all patients born in 1961 550 ms 803 ms 267 ms WIP Find all encounters where patient name contain some word 1000 ms 3000 ms 1000 ms WIP Find encounters of practitioner X since Y 350 ms ~60000 ms 233 ms WIP
- 17. Evaluation criteria 17 • Flexibility – possibility to add new resources and extend existing ones • Response time – the amount of time taken to respond to a request • Scalability – capability of a system to handle a growing amount of data • Independent – ability to work on different databases
- 18. Estimation of Search implementations 18 Features #1 Table per Resource #2 Custom index #3 Non-SQL + JSON/XML index #4 BigData Response time (simple queries) Response time (complex queries) WIP Flexibility / extensibility Scalability Platform independent Yes Yes No No Easy to develop WIP