Creating demo patient data for OHIE 1.0

Legacy openhie-shr
1

Hi,

I’m working on getting some demo patient data prepared for OHIE 1.0.

As a part of this, i’m setting up the SHR as Ryan documented on:

https://wiki.ohie.org/display/documents/How+to+setup+and+configure+the+OpenHIE+reference+applications?flashId=2016813600

So, a few questions,

(1) Does anyone have any sample APHP or APS messages that can be posted into the SHR, just to demonstrate that it works ?

(2) Can the APHP and APS messages work against the terminology registry setup for the older pre-CDA version of OHIE ?

I’m planning to create demo data for OHIE 1.0 by using de-identified hl7 V2 generated by the RHIE system, converting it into CDA and shooting them into the OHIE using the functionality Ryan C. and Justin developed.

Any thoughts on this process ? would it be easier to just hack a module to shoot the HL7 V2 messages into the SHR without any V2 to CDA conversion ?

···

Best Regards,
Suranga

2

Hi,

Another issue that i’m faced with.

Since my demo data is based on the RHIE, i’m not sure how well it maps with the APHP and APS documents.

For example, assume that I have a database full of RHIE based data.

Now, I request an APHP document for a patient from this database.

So the problem is, do the concept mappings / terminology sets introduced for the CDA documents map with what we had in place for the hl7 v2 based RHIE ? Will I end up with a blank APHP message, or will I have good data in my document ? :slight_smile:

···

On Fri, Dec 19, 2014 at 12:03 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

I’m working on getting some demo patient data prepared for OHIE 1.0.

As a part of this, i’m setting up the SHR as Ryan documented on:

https://wiki.ohie.org/display/documents/How+to+setup+and+configure+the+OpenHIE+reference+applications?flashId=2016813600

So, a few questions,

(1) Does anyone have any sample APHP or APS messages that can be posted into the SHR, just to demonstrate that it works ?

(2) Can the APHP and APS messages work against the terminology registry setup for the older pre-CDA version of OHIE ?

I’m planning to create demo data for OHIE 1.0 by using de-identified hl7 V2 generated by the RHIE system, converting it into CDA and shooting them into the OHIE using the functionality Ryan C. and Justin developed.

Best Regards,
Suranga

Any thoughts on this process ? would it be easier to just hack a module to shoot the HL7 V2 messages into the SHR without any V2 to CDA conversion ?

–

Best Regards,
Suranga

3

Hi Suranga.

If the data went INTO the SHR as an APHP or as an APS… then it will certainly contain all the data necessary and these will have been coded appropriately via the “discrete data import” routines that are invoked as part of the save encounter workflow. If the database is from RHIE and these data were not run thru the save encounter workflow, then they may or may not be in the right format. Have you run some experiments to see?

Regarding the query for encounter workflow – I will look for Ryan C or Justin to wade in on this to clarify or correct – but my understanding is that this workflow invokes the SHR’s “on demand document” routine and this generates a CCD (not an APS or APHP) which is returned to the point of service application. This CCD is at level 3 for all CDA sections where 100% of the discrete data is available in the SHR and at level 2 otherwise. To request a specific APS or an APHP, you will have had to have first saved it to the document store (and it will have been parsed and saved to the SHR as well).

Suranga, I think you should be able to generate CCDs from the discrete data from an RHIE database… but I’m not sure how fulsome they will be. We should probably expect that the RHIE database is unlikely to be 100% compatible with an OpenHIE database.

Warmest regards, and happy holidays,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

···

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Monday, December 22, 2014 1:01 PM
To: openhie-shr
Subject: Re: Creating demo patient data for OHIE 1.0

Hi,

Another issue that i’m faced with.

Since my demo data is based on the RHIE, i’m not sure how well it maps with the APHP and APS documents.

For example, assume that I have a database full of RHIE based data.

Now, I request an APHP document for a patient from this database.

So the problem is, do the concept mappings / terminology sets introduced for the CDA documents map with what we had in place for the hl7 v2 based RHIE ? Will I end up with a blank APHP message, or will I have good data in my document ? :slight_smile:

On Fri, Dec 19, 2014 at 12:03 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

I’m working on getting some demo patient data prepared for OHIE 1.0.

As a part of this, i’m setting up the SHR as Ryan documented on:

https://wiki.ohie.org/display/documents/How+to+setup+and+configure+the+OpenHIE+reference+applications?flashId=2016813600

So, a few questions,

(1) Does anyone have any sample APHP or APS messages that can be posted into the SHR, just to demonstrate that it works ?

(2) Can the APHP and APS messages work against the terminology registry setup for the older pre-CDA version of OHIE ?

I’m planning to create demo data for OHIE 1.0 by using de-identified hl7 V2 generated by the RHIE system, converting it into CDA and shooting them into the OHIE using the functionality Ryan C. and Justin developed.

Any thoughts on this process ? would it be easier to just hack a module to shoot the HL7 V2 messages into the SHR without any V2 to CDA conversion ?

–

Best Regards,

Suranga

–

Best Regards,

Suranga

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

Thanks Derek -

A couple clarifying questions:

I don’t recall whether the Rwanda transactions fully support the APHP / APS transactions - do they?

I concur with running a few ‘experiments’ to see what type of documents are retrieved from the Rwanda SHR. (aren’t HL7 v2 documents returned?)

The current OpenHIE workflow entitled, “Query patient-level clinical data”, specifies supplying an “XDS.b response - with CDA document content” in response to a query for patient encounters. Is this specific enough for Suranga’s purposes?

Best,

Shaun

···

On Mon, Dec 22, 2014 at 1:23 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga.

If the data went INTO the SHR as an APHP or as an APS… then it will certainly contain all the data necessary and these will have been coded appropriately via the “discrete data import” routines that are invoked as part of the save encounter workflow. If the database is from RHIE and these data were not run thru the save encounter workflow, then they may or may not be in the right format. Have you run some experiments to see?

Regarding the query for encounter workflow – I will look for Ryan C or Justin to wade in on this to clarify or correct – but my understanding is that this workflow invokes the SHR’s “on demand document” routine and this generates a CCD (not an APS or APHP) which is returned to the point of service application. This CCD is at level 3 for all CDA sections where 100% of the discrete data is available in the SHR and at level 2 otherwise. To request a specific APS or an APHP, you will have had to have first saved it to the document store (and it will have been parsed and saved to the SHR as well).

Suranga, I think you should be able to generate CCDs from the discrete data from an RHIE database… but I’m not sure how fulsome they will be. We should probably expect that the RHIE database is unlikely to be 100% compatible with an OpenHIE database.

Warmest regards, and happy holidays,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Monday, December 22, 2014 1:01 PM
To: openhie-shr
Subject: Re: Creating demo patient data for OHIE 1.0

Hi,

Another issue that i’m faced with.

Since my demo data is based on the RHIE, i’m not sure how well it maps with the APHP and APS documents.

For example, assume that I have a database full of RHIE based data.

Now, I request an APHP document for a patient from this database.

So the problem is, do the concept mappings / terminology sets introduced for the CDA documents map with what we had in place for the hl7 v2 based RHIE ? Will I end up with a blank APHP message, or will I have good data in my document ? :slight_smile:

On Fri, Dec 19, 2014 at 12:03 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

I’m working on getting some demo patient data prepared for OHIE 1.0.

As a part of this, i’m setting up the SHR as Ryan documented on:

https://wiki.ohie.org/display/documents/How+to+setup+and+configure+the+OpenHIE+reference+applications?flashId=2016813600

So, a few questions,

(1) Does anyone have any sample APHP or APS messages that can be posted into the SHR, just to demonstrate that it works ?

(2) Can the APHP and APS messages work against the terminology registry setup for the older pre-CDA version of OHIE ?

I’m planning to create demo data for OHIE 1.0 by using de-identified hl7 V2 generated by the RHIE system, converting it into CDA and shooting them into the OHIE using the functionality Ryan C. and Justin developed.

Any thoughts on this process ? would it be easier to just hack a module to shoot the HL7 V2 messages into the SHR without any V2 to CDA conversion ?

–

Best Regards,

Suranga

–

Best Regards,

Suranga

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

5

Hi Shaun.

I don’t think the RHIE transactions were designed to emulate either APS or APHP. That said, the practice of maternal care is generally consistent enough that content in the RHIE messages should not be far off the content in these CDAs – and I’m sure they’re not. Do they fully support APHP and/or APS? No, I don’t think they do.

A query for content against the OpenSHR will return either the specific document that has been asked for (in cases where a document ID has been specified) or a generic “on-demand” document, which is a care summary record returned as a CCD.

Suranga, I’m sorry but I’m not certain what are your purposes. I will assume you’re attempting to develop test scenarios. Two obvious ones are:

  1.  I have saved a clinical document with document ID “x” to the HIE and I want to retrieve that document.

  2.  I want to retrieve an “on demand” health summary document for patient ID “y”.

There are variations on this and, of course, exceptions that will be thrown under a number of conditions – but these two things are bread-and-butter transactions.

I hope this is helpful. I’ve cc’d Justin on this thread in case he wants to wade in with his much-deeper insights. :wink:

Warmest regards, and happy Christmas,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

···

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Monday, December 22, 2014 2:24 PM
To: Derek Ritz (ecGroup)
Cc: Suranga Kasthurirathne; openhie-shr
Subject: Re: Creating demo patient data for OHIE 1.0

Thanks Derek -

A couple clarifying questions:

I don’t recall whether the Rwanda transactions fully support the APHP / APS transactions - do they?

I concur with running a few ‘experiments’ to see what type of documents are retrieved from the Rwanda SHR. (aren’t HL7 v2 documents returned?)

The current OpenHIE workflow entitled, “Query patient-level clinical data”, specifies supplying an “XDS.b response - with CDA document content” in response to a query for patient encounters. Is this specific enough for Suranga’s purposes?

Best,

Shaun

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Mon, Dec 22, 2014 at 1:23 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga.

If the data went INTO the SHR as an APHP or as an APS… then it will certainly contain all the data necessary and these will have been coded appropriately via the “discrete data import” routines that are invoked as part of the save encounter workflow. If the database is from RHIE and these data were not run thru the save encounter workflow, then they may or may not be in the right format. Have you run some experiments to see?

Regarding the query for encounter workflow – I will look for Ryan C or Justin to wade in on this to clarify or correct – but my understanding is that this workflow invokes the SHR’s “on demand document” routine and this generates a CCD (not an APS or APHP) which is returned to the point of service application. This CCD is at level 3 for all CDA sections where 100% of the discrete data is available in the SHR and at level 2 otherwise. To request a specific APS or an APHP, you will have had to have first saved it to the document store (and it will have been parsed and saved to the SHR as well).

Suranga, I think you should be able to generate CCDs from the discrete data from an RHIE database… but I’m not sure how fulsome they will be. We should probably expect that the RHIE database is unlikely to be 100% compatible with an OpenHIE database.

Warmest regards, and happy holidays,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Monday, December 22, 2014 1:01 PM
To: openhie-shr
Subject: Re: Creating demo patient data for OHIE 1.0

Hi,

Another issue that i’m faced with.

Since my demo data is based on the RHIE, i’m not sure how well it maps with the APHP and APS documents.

For example, assume that I have a database full of RHIE based data.

Now, I request an APHP document for a patient from this database.

So the problem is, do the concept mappings / terminology sets introduced for the CDA documents map with what we had in place for the hl7 v2 based RHIE ? Will I end up with a blank APHP message, or will I have good data in my document ? :slight_smile:

On Fri, Dec 19, 2014 at 12:03 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

I’m working on getting some demo patient data prepared for OHIE 1.0.

As a part of this, i’m setting up the SHR as Ryan documented on:

https://wiki.ohie.org/display/documents/How+to+setup+and+configure+the+OpenHIE+reference+applications?flashId=2016813600

So, a few questions,

(1) Does anyone have any sample APHP or APS messages that can be posted into the SHR, just to demonstrate that it works ?

(2) Can the APHP and APS messages work against the terminology registry setup for the older pre-CDA version of OHIE ?

I’m planning to create demo data for OHIE 1.0 by using de-identified hl7 V2 generated by the RHIE system, converting it into CDA and shooting them into the OHIE using the functionality Ryan C. and Justin developed.

Any thoughts on this process ? would it be easier to just hack a module to shoot the HL7 V2 messages into the SHR without any V2 to CDA conversion ?

–

Best Regards,

Suranga

–

Best Regards,

Suranga

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

6

Hi all,

To clarify,

  1. My purpose is to generate test data that can be used to demonstrate all capabilities of V3 enabled OpenHIE 1.0. To me, testing save/query transactions is rather a byproduct. I’m more interested in building realistic data for demonstration purposes.

  2. I agree with Derek, if the data goes into the SHR as APS or APHP, then it will be appropriately coded, and retrievable. If I can realistically translate my V2 into V3 and map the codesets correctly, our problems would be solved, and I would be happy to do so.

  3. As Derek mentioned, the RHIE data is not v3 friendly, and so it is not properly coded. Based on what I’ve seen of APHP and APS, I don’t think the code sets their profiles use match up to what we have in the RHIE V2 messages. And so, mapping between the two may be necessary.

  4. Justin, I haven’t followed your latest work on the SHR is detail, but i’d like to hear your opinion on the possibility of using RHIE (v2 data) with OpenHIE (V3) systems, and how much codeset mapping it involves.

  5. To Derek’s point, I can convert the RHIE data into CCD’s (we at OpenMRS have a module for that…) But, then again, we’d need to re-convert it to APHP, so not sure if we want to go down that road ?

Best regards,

Suranga

···

On Mon, Dec 22, 2014 at 4:24 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Shaun.

I don’t think the RHIE transactions were designed to emulate either APS or APHP. That said, the practice of maternal care is generally consistent enough that content in the RHIE messages should not be far off the content in these CDAs – and I’m sure they’re not. Do they fully support APHP and/or APS? No, I don’t think they do.

A query for content against the OpenSHR will return either the specific document that has been asked for (in cases where a document ID has been specified) or a generic “on-demand” document, which is a care summary record returned as a CCD.

Suranga, I’m sorry but I’m not certain what are your purposes. I will assume you’re attempting to develop test scenarios. Two obvious ones are:

  1.  I have saved a clinical document with document ID “x” to the HIE and I want to retrieve that document.

  1.  I want to retrieve an “on demand” health summary document for patient ID “y”.

There are variations on this and, of course, exceptions that will be thrown under a number of conditions – but these two things are bread-and-butter transactions.

I hope this is helpful. I’ve cc’d Justin on this thread in case he wants to wade in with his much-deeper insights. :wink:

Warmest regards, and happy Christmas,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Monday, December 22, 2014 2:24 PM
To: Derek Ritz (ecGroup)
Cc: Suranga Kasthurirathne; openhie-shr

Subject: Re: Creating demo patient data for OHIE 1.0

Thanks Derek -

A couple clarifying questions:

I don’t recall whether the Rwanda transactions fully support the APHP / APS transactions - do they?

I concur with running a few ‘experiments’ to see what type of documents are retrieved from the Rwanda SHR. (aren’t HL7 v2 documents returned?)

The current OpenHIE workflow entitled, “Query patient-level clinical data”, specifies supplying an “XDS.b response - with CDA document content” in response to a query for patient encounters. Is this specific enough for Suranga’s purposes?

Best,

Shaun

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Mon, Dec 22, 2014 at 1:23 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi Suranga.

If the data went INTO the SHR as an APHP or as an APS… then it will certainly contain all the data necessary and these will have been coded appropriately via the “discrete data import” routines that are invoked as part of the save encounter workflow. If the database is from RHIE and these data were not run thru the save encounter workflow, then they may or may not be in the right format. Have you run some experiments to see?

Regarding the query for encounter workflow – I will look for Ryan C or Justin to wade in on this to clarify or correct – but my understanding is that this workflow invokes the SHR’s “on demand document” routine and this generates a CCD (not an APS or APHP) which is returned to the point of service application. This CCD is at level 3 for all CDA sections where 100% of the discrete data is available in the SHR and at level 2 otherwise. To request a specific APS or an APHP, you will have had to have first saved it to the document store (and it will have been parsed and saved to the SHR as well).

Suranga, I think you should be able to generate CCDs from the discrete data from an RHIE database… but I’m not sure how fulsome they will be. We should probably expect that the RHIE database is unlikely to be 100% compatible with an OpenHIE database.

Warmest regards, and happy holidays,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Monday, December 22, 2014 1:01 PM
To: openhie-shr
Subject: Re: Creating demo patient data for OHIE 1.0

Hi,

Another issue that i’m faced with.

Since my demo data is based on the RHIE, i’m not sure how well it maps with the APHP and APS documents.

For example, assume that I have a database full of RHIE based data.

Now, I request an APHP document for a patient from this database.

So the problem is, do the concept mappings / terminology sets introduced for the CDA documents map with what we had in place for the hl7 v2 based RHIE ? Will I end up with a blank APHP message, or will I have good data in my document ? :slight_smile:

On Fri, Dec 19, 2014 at 12:03 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:

Hi,

I’m working on getting some demo patient data prepared for OHIE 1.0.

As a part of this, i’m setting up the SHR as Ryan documented on:

https://wiki.ohie.org/display/documents/How+to+setup+and+configure+the+OpenHIE+reference+applications?flashId=2016813600

So, a few questions,

(1) Does anyone have any sample APHP or APS messages that can be posted into the SHR, just to demonstrate that it works ?

(2) Can the APHP and APS messages work against the terminology registry setup for the older pre-CDA version of OHIE ?

I’m planning to create demo data for OHIE 1.0 by using de-identified hl7 V2 generated by the RHIE system, converting it into CDA and shooting them into the OHIE using the functionality Ryan C. and Justin developed.

Any thoughts on this process ? would it be easier to just hack a module to shoot the HL7 V2 messages into the SHR without any V2 to CDA conversion ?

–

Best Regards,

Suranga

–

Best Regards,

Suranga

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

7

Hi Saranga,

I haven’t really seen much of the RHIE v2 data so I can’t give a detailed response about the difficulty mapping the codes. One of the nice things about the CDA handlers is that they can be configured to accept whatever codesets we want to use (that is, it can support non-standard APS/APHP documents). If you want “proper” APS/APHP documents then the task might be a little more difficult. Most likely the data can be mapped as concepts for tracking height/weight/fundal height, etc. aren’t that different I would imagine, however you may need an “intelligent” map that can decipher what the semantic meaning of the code from the v2 data is.

Cheers

-Justin

···

On Tuesday, December 23, 2014 2:59:06 PM UTC-5, Suranga Kasthurirathne wrote:

Hi all,

To clarify,

  1. My purpose is to generate test data that can be used to demonstrate all capabilities of V3 enabled OpenHIE 1.0. To me, testing save/query transactions is rather a byproduct. I’m more interested in building realistic data for demonstration purposes.
  1. I agree with Derek, if the data goes into the SHR as APS or APHP, then it will be appropriately coded, and retrievable. If I can realistically translate my V2 into V3 and map the codesets correctly, our problems would be solved, and I would be happy to do so.
  1. As Derek mentioned, the RHIE data is not v3 friendly, and so it is not properly coded. Based on what I’ve seen of APHP and APS, I don’t think the code sets their profiles use match up to what we have in the RHIE V2 messages. And so, mapping between the two may be necessary.
  1. Justin, I haven’t followed your latest work on the SHR is detail, but i’d like to hear your opinion on the possibility of using RHIE (v2 data) with OpenHIE (V3) systems, and how much codeset mapping it involves.
  1. To Derek’s point, I can convert the RHIE data into CCD’s (we at OpenMRS have a module for that…) But, then again, we’d need to re-convert it to APHP, so not sure if we want to go down that road ?

Best regards,

Suranga

On Mon, Dec 22, 2014 at 4:24 PM, Derek Ritz (ecGroup) derek...@ecgroupinc.com wrote:

Hi Shaun.

I don’t think the RHIE transactions were designed to emulate either APS or APHP. That said, the practice of maternal care is generally consistent enough that content in the RHIE messages should not be far off the content in these CDAs – and I’m sure they’re not. Do they fully support APHP and/or APS? No, I don’t think they do.

A query for content against the OpenSHR will return either the specific document that has been asked for (in cases where a document ID has been specified) or a generic “on-demand” document, which is a care summary record returned as a CCD.

Suranga, I’m sorry but I’m not certain what are your purposes. I will assume you’re attempting to develop test scenarios. Two obvious ones are:

  1.  I have saved a clinical document with document ID “x” to the HIE and I want to retrieve that document.

  1.  I want to retrieve an “on demand” health summary document for patient ID “y”.

There are variations on this and, of course, exceptions that will be thrown under a number of conditions – but these two things are bread-and-butter transactions.

I hope this is helpful. I’ve cc’d Justin on this thread in case he wants to wade in with his much-deeper insights. :wink:

Warmest regards, and happy Christmas,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: Shaun Grannis [mailto:sgra...@gmail.com]
Sent: Monday, December 22, 2014 2:24 PM
To: Derek Ritz (ecGroup)
Cc: Suranga Kasthurirathne; openhie-shr

Subject: Re: Creating demo patient data for OHIE 1.0

Thanks Derek -

A couple clarifying questions:

I don’t recall whether the Rwanda transactions fully support the APHP / APS transactions - do they?

I concur with running a few ‘experiments’ to see what type of documents are retrieved from the Rwanda SHR. (aren’t HL7 v2 documents returned?)

The current OpenHIE workflow entitled, “Query patient-level clinical data”, specifies supplying an “XDS.b response - with CDA document content” in response to a query for patient encounters. Is this specific enough for Suranga’s purposes?

Best,

Shaun

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Mon, Dec 22, 2014 at 1:23 PM, Derek Ritz (ecGroup) derek...@ecgroupinc.com wrote:

Hi Suranga.

If the data went INTO the SHR as an APHP or as an APS… then it will certainly contain all the data necessary and these will have been coded appropriately via the “discrete data import” routines that are invoked as part of the save encounter workflow. If the database is from RHIE and these data were not run thru the save encounter workflow, then they may or may not be in the right format. Have you run some experiments to see?

Regarding the query for encounter workflow – I will look for Ryan C or Justin to wade in on this to clarify or correct – but my understanding is that this workflow invokes the SHR’s “on demand document” routine and this generates a CCD (not an APS or APHP) which is returned to the point of service application. This CCD is at level 3 for all CDA sections where 100% of the discrete data is available in the SHR and at level 2 otherwise. To request a specific APS or an APHP, you will have had to have first saved it to the document store (and it will have been parsed and saved to the SHR as well).

Suranga, I think you should be able to generate CCDs from the discrete data from an RHIE database… but I’m not sure how fulsome they will be. We should probably expect that the RHIE database is unlikely to be 100% compatible with an OpenHIE database.

Warmest regards, and happy holidays,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openh...@googlegroups.com [mailto:openh...@googlegroups.com] On Behalf Of Suranga Kasthurirathne
Sent: Monday, December 22, 2014 1:01 PM
To: openhie-shr
Subject: Re: Creating demo patient data for OHIE 1.0

Hi,

Another issue that i’m faced with.

Since my demo data is based on the RHIE, i’m not sure how well it maps with the APHP and APS documents.

For example, assume that I have a database full of RHIE based data.

Now, I request an APHP document for a patient from this database.

So the problem is, do the concept mappings / terminology sets introduced for the CDA documents map with what we had in place for the hl7 v2 based RHIE ? Will I end up with a blank APHP message, or will I have good data in my document ? :slight_smile:

On Fri, Dec 19, 2014 at 12:03 PM, Suranga Kasthurirathne suran...@gmail.com wrote:

Hi,

I’m working on getting some demo patient data prepared for OHIE 1.0.

As a part of this, i’m setting up the SHR as Ryan documented on:

https://wiki.ohie.org/display/documents/How+to+setup+and+configure+the+OpenHIE+reference+applications?flashId=2016813600

So, a few questions,

(1) Does anyone have any sample APHP or APS messages that can be posted into the SHR, just to demonstrate that it works ?

(2) Can the APHP and APS messages work against the terminology registry setup for the older pre-CDA version of OHIE ?

I’m planning to create demo data for OHIE 1.0 by using de-identified hl7 V2 generated by the RHIE system, converting it into CDA and shooting them into the OHIE using the functionality Ryan C. and Justin developed.

Any thoughts on this process ? would it be easier to just hack a module to shoot the HL7 V2 messages into the SHR without any V2 to CDA conversion ?

–

Best Regards,

Suranga

–

Best Regards,

Suranga

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.