Over the last few months we have been reviewing and tools that could be used as a SHR and have produced a document (link) that explains the conclusions of this review and explains our recommendation. On the community call yesterday we came to the decision that we are happy with the recommendation that is set out in the document and we should move forward with it. To summaries this recommendation is as follows:
OpenMRS is the tool we believe we can have the most success with and we believe it will provide a good base for creating a SHR. We recommend that we move forward with OpenMRS as the tool to use to create a SHR for the needs of OpenHIE.
We also note that there is the RAMRS tool that Regenstrief have developed that also could act as a SHR and this will be taken forward by the Regenstrief team in a separate track to see if it could fit the role to. However, the focus of this community will be to move forward with OpenMRS as the technology choice for the SHR.
If you were not on the call and have specific comments that you would like to add or concerns you would like to raise, please do so. We’d be happy to hear them.
Thanks all for the hard work in getting to this point.
Cheers,
Ryan
···
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Thanks Ryan, I think OpenMRS is definitely a good choice and I feel confident that we can build a great SHR tool around it.
I wonder if we are ready to start delving a little bit more into the design of the SHR around OpenMRS now? As stated in the recommendation documents, the largest issue we face around OpenMRS is the storing of document-based data. I’ve been reading up on the pro’s and con’s of storing blobs in relational databases and think this will make for quite an interesting discussion.
Personally I feel we should NOT be storing BLOBS (images etc) directly in the obs table. This could lead the database to grow in size very quickly and from what I gather it will lead to much slower performance, as the database is usually the bottleneck. It also consumes more space than storing files directly on the filesystem and it makes your backup process much more cumbersome. For example, you can do incremental backups of a directory on a FS off-site using rsync, but you can’t do this when everything is stored in a database that could grow to be 100’s of GB or TB’s due to network bandwidth limitations.
The main issue with storing files separately (whether on a filesystem or in a distributed NoSQL type database) is that referential integrity and auditing is harder to achieve. Typically this would require a file path or URL to the file to be stored as a simple observation in the database, but it’s possible that files can get deleted or changed without this being reflected in the record in the database. SQL Server 2008 allows you to have a file pointer as a datatype, but not MySQL or PostgreSQL, which is what OpenMRS uses.
I look forward to hearing other people’s thoughts on this.
Kind regards,
Kari
···
On Wednesday, August 14, 2013 9:38:45 AM UTC+2, Ryan Crichton wrote:
Hi all,
Over the last few months we have been reviewing and tools that could be used as a SHR and have produced a document (link) that explains the conclusions of this review and explains our recommendation. On the community call yesterday we came to the decision that we are happy with the recommendation that is set out in the document and we should move forward with it. To summaries this recommendation is as follows:
OpenMRS is the tool we believe we can have the most success with and we believe it will provide a good base for creating a SHR. We recommend that we move forward with OpenMRS as the tool to use to create a SHR for the needs of OpenHIE.
We also note that there is the RAMRS tool that Regenstrief have developed that also could act as a SHR and this will be taken forward by the Regenstrief team in a separate track to see if it could fit the role to. However, the focus of this community will be to move forward with OpenMRS as the technology choice for the SHR.
If you were not on the call and have specific comments that you would like to add or concerns you would like to raise, please do so. We’d be happy to hear them.
Thanks all for the hard work in getting to this point.
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Thanks for raising this issue Kari (and for the offline discussion). I think these are great issues to think of addressing as part of the design concepts as we move forward. Looking forward to seeing the rest of the group weigh in too.
On a first pass my thought is that we need to decide at a high level the best method to handle document data types (my preference is a document based db – my bias is now out there) and then figure out the technical challenges in this. As you have raised there are concerns around the management of referencial integrity between the two as well as the ability to audit too. Personally I think we can design a solution that allows us to mitigate it but I would love to hear the larger groups thoughts on this too.
Cheers,
Carl
···
On Fri, Aug 16, 2013 at 11:44 AM, Kari Schoonbee kari@jembi.org wrote:
Thanks Ryan, I think OpenMRS is definitely a good choice and I feel confident that we can build a great SHR tool around it.
I wonder if we are ready to start delving a little bit more into the design of the SHR around OpenMRS now? As stated in the recommendation documents, the largest issue we face around OpenMRS is the storing of document-based data. I’ve been reading up on the pro’s and con’s of storing blobs in relational databases and think this will make for quite an interesting discussion.
Personally I feel we should NOT be storing BLOBS (images etc) directly in the obs table. This could lead the database to grow in size very quickly and from what I gather it will lead to much slower performance, as the database is usually the bottleneck. It also consumes more space than storing files directly on the filesystem and it makes your backup process much more cumbersome. For example, you can do incremental backups of a directory on a FS off-site using rsync, but you can’t do this when everything is stored in a database that could grow to be 100’s of GB or TB’s due to network bandwidth limitations.
The main issue with storing files separately (whether on a filesystem or in a distributed NoSQL type database) is that referential integrity and auditing is harder to achieve. Typically this would require a file path or URL to the file to be stored as a simple observation in the database, but it’s possible that files can get deleted or changed without this being reflected in the record in the database. SQL Server 2008 allows you to have a file pointer as a datatype, but not MySQL or PostgreSQL, which is what OpenMRS uses.
I look forward to hearing other people’s thoughts on this.
Kind regards,
Kari
On Wednesday, August 14, 2013 9:38:45 AM UTC+2, Ryan Crichton wrote:
Hi all,
Over the last few months we have been reviewing and tools that could be used as a SHR and have produced a document (link) that explains the conclusions of this review and explains our recommendation. On the community call yesterday we came to the decision that we are happy with the recommendation that is set out in the document and we should move forward with it. To summaries this recommendation is as follows:
OpenMRS is the tool we believe we can have the most success with and we believe it will provide a good base for creating a SHR. We recommend that we move forward with OpenMRS as the tool to use to create a SHR for the needs of OpenHIE.
We also note that there is the RAMRS tool that Regenstrief have developed that also could act as a SHR and this will be taken forward by the Regenstrief team in a separate track to see if it could fit the role to. However, the focus of this community will be to move forward with OpenMRS as the technology choice for the SHR.
If you were not on the call and have specific comments that you would like to add or concerns you would like to raise, please do so. We’d be happy to hear them.
Thanks all for the hard work in getting to this point.
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
– Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl@jembi.org
Thanks for raising these issues. This is definitely the right time to be delving into some of the more design specific details of the SHR. Our focus for the coming calls will be to discuss these issues in detail and produce design documentation describing our feel for the best way to approach these issues.
I agree storing documents in a relation database may not be the most ideal. It would be interesting to explore how OpenXDS manages documents, that could help us in identifying a direction that is known to work.
Cheers,
Ryan
···
On Fri, Aug 16, 2013 at 1:18 PM, Carl Fourie carl@jembi.org wrote:
Thanks for raising this issue Kari (and for the offline discussion). I think these are great issues to think of addressing as part of the design concepts as we move forward. Looking forward to seeing the rest of the group weigh in too.
On a first pass my thought is that we need to decide at a high level the best method to handle document data types (my preference is a document based db – my bias is now out there) and then figure out the technical challenges in this. As you have raised there are concerns around the management of referencial integrity between the two as well as the ability to audit too. Personally I think we can design a solution that allows us to mitigate it but I would love to hear the larger groups thoughts on this too.
Cheers,
Carl
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
On Fri, Aug 16, 2013 at 11:44 AM, Kari Schoonbee kari@jembi.org wrote:
Thanks Ryan, I think OpenMRS is definitely a good choice and I feel confident that we can build a great SHR tool around it.
I wonder if we are ready to start delving a little bit more into the design of the SHR around OpenMRS now? As stated in the recommendation documents, the largest issue we face around OpenMRS is the storing of document-based data. I’ve been reading up on the pro’s and con’s of storing blobs in relational databases and think this will make for quite an interesting discussion.
Personally I feel we should NOT be storing BLOBS (images etc) directly in the obs table. This could lead the database to grow in size very quickly and from what I gather it will lead to much slower performance, as the database is usually the bottleneck. It also consumes more space than storing files directly on the filesystem and it makes your backup process much more cumbersome. For example, you can do incremental backups of a directory on a FS off-site using rsync, but you can’t do this when everything is stored in a database that could grow to be 100’s of GB or TB’s due to network bandwidth limitations.
The main issue with storing files separately (whether on a filesystem or in a distributed NoSQL type database) is that referential integrity and auditing is harder to achieve. Typically this would require a file path or URL to the file to be stored as a simple observation in the database, but it’s possible that files can get deleted or changed without this being reflected in the record in the database. SQL Server 2008 allows you to have a file pointer as a datatype, but not MySQL or PostgreSQL, which is what OpenMRS uses.
I look forward to hearing other people’s thoughts on this.
Kind regards,
Kari
On Wednesday, August 14, 2013 9:38:45 AM UTC+2, Ryan Crichton wrote:
Hi all,
Over the last few months we have been reviewing and tools that could be used as a SHR and have produced a document (link) that explains the conclusions of this review and explains our recommendation. On the community call yesterday we came to the decision that we are happy with the recommendation that is set out in the document and we should move forward with it. To summaries this recommendation is as follows:
OpenMRS is the tool we believe we can have the most success with and we believe it will provide a good base for creating a SHR. We recommend that we move forward with OpenMRS as the tool to use to create a SHR for the needs of OpenHIE.
We also note that there is the RAMRS tool that Regenstrief have developed that also could act as a SHR and this will be taken forward by the Regenstrief team in a separate track to see if it could fit the role to. However, the focus of this community will be to move forward with OpenMRS as the technology choice for the SHR.
If you were not on the call and have specific comments that you would like to add or concerns you would like to raise, please do so. We’d be happy to hear them.
Thanks all for the hard work in getting to this point.
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
– Carl Fourie
Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl@jembi.org