This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Persisting FHIR Resources"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | [[ | + | Development of this [[AID]] whitepaper is discontinued. See [[FHIR Server Design]]. |
− | + | ||
+ | --- | ||
+ | |||
Lead author/editor: Andy | Lead author/editor: Andy | ||
Line 26: | Line 28: | ||
*Jan Wittenber jan.wittenber@philips.com | *Jan Wittenber jan.wittenber@philips.com | ||
**Comment: There's a data type in ISO/IEEE 11073, 'Persistant Metric Stoe (PMS)', that might be of interest. | **Comment: There's a data type in ISO/IEEE 11073, 'Persistant Metric Stoe (PMS)', that might be of interest. | ||
+ | *Nikolay Ryzhikov niquola@gmail.com | ||
+ | **FHIR persistence in PostgreSQL (https://github.com/fhirbase/fhirbase); also interested in newSQL solutions (datomic, casandra etc) |
Latest revision as of 12:26, 14 April 2016
Development of this AID whitepaper is discontinued. See FHIR Server Design.
---
Lead author/editor: Andy
Summary
- From discussions during the September 2012 WGM
- There are three approaches that have already been taken for persisting FHIR resources.
- Just each resource by itself with links
- Enough of a them linked together to be equivalent to a clinical statement or what we previously referred to as a SMIRF
- Entire CDA like documents that contain many clinical statements within them.
- The experiences of persisting FHIR resources in any of the “clusters” above in the various “NoSQL” databases such as MongoDB (Ewout), CouchDB (Gordon), ?? (PHI), XML (Van Der Zel).
- There are three approaches that have already been taken for persisting FHIR resources.
(potential) authors/contributors
- Eve Marcelina Rubillos emfrubillos@gmail.com
- I would want to volunteer in writing or creating this whitepaper. I am quite new to FHIR, it has only been a little over a month since I have been joining conference calls whenever my time permits, thus, I would prefer working with a team.
- david hay david.hay25@gmail.com
- I'm happy to be a reviewer / contributor - especially in the noSql space - but there are better qualified lead authors out there..
- alex.zupan@tbsgroup.com alex.zupan@tbsgroup.com
- Alex can provide info on our O-R (Hibernate) approach, starting from the class diagram down to the physical db model (tested on Oracle and MySql).
- Charles McCay charlie@ramseysystems.co.uk
- I may be able to offer some example content from the semantichealthnet project
- George de la Torre delatorre.george@gmail.com
- Something is missing here, "event sourcing", we should be open to any strategies, the white paper should demonstrate the benefits of options. Also, familiar with the other persistence methods, ORM, NoSQL, Graph, JDBC, SQL, and even Mumps (Cache) :)
- Certainly, at least, I can contribute to writing up the "event sourcing" section, with FHIR as regard to RIM (missing here).
- Jan Wittenber jan.wittenber@philips.com
- Comment: There's a data type in ISO/IEEE 11073, 'Persistant Metric Stoe (PMS)', that might be of interest.
- Nikolay Ryzhikov niquola@gmail.com
- FHIR persistence in PostgreSQL (https://github.com/fhirbase/fhirbase); also interested in newSQL solutions (datomic, casandra etc)