Download as PDF, PPTX
![#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)
Uploaded byIgor Bossenko
FHIR Developer Days 2015. Study on db implementations for FHIR server
The document discusses the implementation of a FHIR server for health information exchange in Lithuania, detailing various database approaches including traditional RDBMS, resource store with custom indexing, non-SQL methods, and big data solutions. It evaluates each approach based on flexibility, response time, and scalability, providing specific query examples and their performance metrics. Overall, the study highlights the trade-offs between different database structures while addressing requirements for healthcare data accessibility.
More Related Content
Similar to FHIR Developer Days 2015. Study on db implementations for FHIR server
FHIR Developer Days 2015. Study on db implementations for FHIR server
- 1. Nortal NHS inLithuania - 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 perresource or datatype 4
- 5. #1 Query examples5 Select * from Condition where Encounter_ID = 123; Select * from Human_Name_Part where Name_Part_Code = ‘family’ and value = ‘XXX’;
- 6. #1 Table perresource 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 examples8 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 JSONBquery 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 ResourceRows 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 Searchimplementations 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
- 19.