I’m back after a brief hiatus (albeit wearing a different hat now) and am trying to catch up on the SHR before the next community call. Please forgive any obvious / stupid comments you may find below
I understand and agree with the concept of operating multiple data stores in parallel for the SHR. But my question is, what are our plans to ensure compliance / integrate our design with the future OMRS architectural path ? For example, the current OMRS RBDMS also stores hl7 messages and other document based data, so they may be interested in adopting the hybrid approach as proposed here.
Is our plan to introduce a new OMRS module which would be responsible for managing interactions with the new non-relational database ? Depending on how OpenMRS decides to manage its document based data, perhaps this could even be turned into a core module in the distant future ?
Since we already have some document based data stored in the relational database, the first step after implementing a non-relational DB would be to move this data over, and figure out means for allowing the SHR to identify the new location of this data ?
And also, what specific data do we want to move out to the Document based DB ? is it just hl7 messages, text files/pdf’s and images ? I foresee that we may need to override a certain amount of default OMRS behavior, which may be rather tricky…
At the moment we don’t have a complete plan for how we want to use OpenMRS to store unstructured data. Those discussion still need to occur. Thanks for bringing up these key issues, we will need to come up with a design that considers each one of those. It would be great if you could join the SHR calls that occur every 2 weeks if possible. You can find the details for these calls on the OpenHIE wiki (https://wiki.ohie.org/display/resources/Shared+Health+Record+Community+Call) and you can see some of the things we plan to do to OpenMRS to support for the needs of OpenHIE: https://wiki.ohie.org/display/SUB/OpenMRS+as+the+SHR+design+document
Cheers,
Ryan
···
On Sat, Aug 31, 2013 at 9:25 PM, Suranga Kasthurirathne suranga@jembi.org wrote:
Hi,
I’m back after a brief hiatus (albeit wearing a different hat now) and am trying to catch up on the SHR before the next community call. Please forgive any obvious / stupid comments you may find below
I understand and agree with the concept of operating multiple data stores in parallel for the SHR. But my question is, what are our plans to ensure compliance / integrate our design with the future OMRS architectural path ? For example, the current OMRS RBDMS also stores hl7 messages and other document based data, so they may be interested in adopting the hybrid approach as proposed here.
Is our plan to introduce a new OMRS module which would be responsible for managing interactions with the new non-relational database ? Depending on how OpenMRS decides to manage its document based data, perhaps this could even be turned into a core module in the distant future ?
Since we already have some document based data stored in the relational database, the first step after implementing a non-relational DB would be to move this data over, and figure out means for allowing the SHR to identify the new location of this data ?
And also, what specific data do we want to move out to the Document based DB ? is it just hl7 messages, text files/pdf’s and images ? I foresee that we may need to override a certain amount of default OMRS behavior, which may be rather tricky…
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
Thanks, it looks like I’ve overshot our mark there. I did read the document, but apparently i’d made some assumptions as to how far along the process we really were.
But anyway, looking forward to the next call
Best regards,
Suranga
···
On Mon, Sep 2, 2013 at 11:11 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Suranga,
Thanks for joining the community
At the moment we don’t have a complete plan for how we want to use OpenMRS to store unstructured data. Those discussion still need to occur. Thanks for bringing up these key issues, we will need to come up with a design that considers each one of those. It would be great if you could join the SHR calls that occur every 2 weeks if possible. You can find the details for these calls on the OpenHIE wiki (https://wiki.ohie.org/display/resources/Shared+Health+Record+Community+Call) and you can see some of the things we plan to do to OpenMRS to support for the needs of OpenHIE: https://wiki.ohie.org/display/SUB/OpenMRS+as+the+SHR+design+document
Cheers,
Ryan
On Sat, Aug 31, 2013 at 9:25 PM, Suranga Kasthurirathne suranga@jembi.org wrote:
Hi,
I’m back after a brief hiatus (albeit wearing a different hat now) and am trying to catch up on the SHR before the next community call. Please forgive any obvious / stupid comments you may find below
I understand and agree with the concept of operating multiple data stores in parallel for the SHR. But my question is, what are our plans to ensure compliance / integrate our design with the future OMRS architectural path ? For example, the current OMRS RBDMS also stores hl7 messages and other document based data, so they may be interested in adopting the hybrid approach as proposed here.
Is our plan to introduce a new OMRS module which would be responsible for managing interactions with the new non-relational database ? Depending on how OpenMRS decides to manage its document based data, perhaps this could even be turned into a core module in the distant future ?
Since we already have some document based data stored in the relational database, the first step after implementing a non-relational DB would be to move this data over, and figure out means for allowing the SHR to identify the new location of this data ?
And also, what specific data do we want to move out to the Document based DB ? is it just hl7 messages, text files/pdf’s and images ? I foresee that we may need to override a certain amount of default OMRS behavior, which may be rather tricky…
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
