As discussed on the call yesterday, I’ve attached some sample CDAs generated from the On-Demand-Documents module. Please note that the display names for some of the codes may be inaccurate as these were generated from unit tests and aren’t using the complete CIEL database (which is also why matches , in reality is the reference term’s display name and will be the MVP/CIEL preferred name).
There are four documents from four patients:
Sample 1 : Represents a CCD for a patient where only Level 2 data is available. The data is fed from two encounters (APHP documents).
Sample 2 : Represents a CCD for a patient where only Level 3 data has been submitted. This data is fed from one sample C32 document that was imported. Note that level 3 text (as recommended in CCD) is derived from the entries, and original comments (from the original document) are placed in the notes column of the generated text.
Sample 3: Represents a CCD for a patient where only Level 3 vital signs and problems have been submitted, fed from a sample XPHR document from CapMed
Sample 4: Represents a CCD for a patient where only the Vital Signs are Level 3 and Family History is level 2.
I am working on the medications section next, which is perhaps the most complex of the sections to generate, and will post more samples once this is completed. All documents passed the NIST validation tool (when they were originally generated).
I have completed medications and immunizations generation in the ODD module and thought I would just share some examples. I’ve attached a CCD which has several medications and immunizations. Please note that this module code does not yet take into account the “unknown” condition. For example, within an APS or APHP for a point of care system to publish a medications section as:
History of Immunizations
The current implementation of the ODD generation will take this as an observation into OpenMRS’ data model which technically isn’t correct behavior (or it might be). Currently if I receive an APS/APHP/IC document with this and then a subsequent document with medications, the ODD module will generate:
Medication 1
Medication 2
Drug Treatment Unknown
I was wondering what the best way of handling this was? I can either
When I receive “drug treatment unknown” not import the observation into OpenMRS, however this makes detection of Level 2 / 3 data a little more complex, or
When I generate an ODD I can remove “drug treatment unknown” obs. If there are left-over drug obs, I’ll generate those if not I’ll generate a single “drug treatment unknown” entry.
Cheers
-Justin
PS: I have also attached an HTML version of the CCD with the XSL applied.
On Wednesday, September 24, 2014 11:03:08 AM UTC-4, Justin Fyfe wrote:
Hello All,
As discussed on the call yesterday, I’ve attached some sample CDAs generated from the On-Demand-Documents module. Please note that the display names for some of the codes may be inaccurate as these were generated from unit tests and aren’t using the complete CIEL database (which is also why matches , in reality is the reference term’s display name and will be the MVP/CIEL preferred name).
There are four documents from four patients:
Sample 1 : Represents a CCD for a patient where only Level 2 data is available. The data is fed from two encounters (APHP documents).
Sample 2 : Represents a CCD for a patient where only Level 3 data has been submitted. This data is fed from one sample C32 document that was imported. Note that level 3 text (as recommended in CCD) is derived from the entries, and original comments (from the original document) are placed in the notes column of the generated text.
Sample 3: Represents a CCD for a patient where only Level 3 vital signs and problems have been submitted, fed from a sample XPHR document from CapMed
Sample 4: Represents a CCD for a patient where only the Vital Signs are Level 3 and Family History is level 2.
I am working on the medications section next, which is perhaps the most complex of the sections to generate, and will post more samples once this is completed. All documents passed the NIST validation tool (when they were originally generated).
I don’t know enough about CCD to comment, but from your description of the problem it sounds like number 2 might be the better option. I’d think it would be better to import as much data as possible and work around it than to not import certain bits of data. However, I think your judgement would be best to determine what is most appropriate.
I have completed medications and immunizations generation in the ODD module and thought I would just share some examples. I’ve attached a CCD which has several medications and immunizations. Please note that this module code does not yet take into account the “unknown” condition. For example, within an APS or APHP for a point of care system to publish a medications section as:
History of Immunizations
The current implementation of the ODD generation will take this as an observation into OpenMRS’ data model which technically isn’t correct behavior (or it might be). Currently if I receive an APS/APHP/IC document with this and then a subsequent document with medications, the ODD module will generate:
Medication 1
Medication 2
Drug Treatment Unknown
I was wondering what the best way of handling this was? I can either
When I receive “drug treatment unknown” not import the observation into OpenMRS, however this makes detection of Level 2 / 3 data a little more complex, or
When I generate an ODD I can remove “drug treatment unknown” obs. If there are left-over drug obs, I’ll generate those if not I’ll generate a single “drug treatment unknown” entry.
Cheers
-Justin
PS: I have also attached an HTML version of the CCD with the XSL applied.
On Wednesday, September 24, 2014 11:03:08 AM UTC-4, Justin Fyfe wrote:
Hello All,
As discussed on the call yesterday, I’ve attached some sample CDAs generated from the On-Demand-Documents module. Please note that the display names for some of the codes may be inaccurate as these were generated from unit tests and aren’t using the complete CIEL database (which is also why matches , in reality is the reference term’s display name and will be the MVP/CIEL preferred name).
There are four documents from four patients:
Sample 1 : Represents a CCD for a patient where only Level 2 data is available. The data is fed from two encounters (APHP documents).
Sample 2 : Represents a CCD for a patient where only Level 3 data has been submitted. This data is fed from one sample C32 document that was imported. Note that level 3 text (as recommended in CCD) is derived from the entries, and original comments (from the original document) are placed in the notes column of the generated text.
Sample 3: Represents a CCD for a patient where only Level 3 vital signs and problems have been submitted, fed from a sample XPHR document from CapMed
Sample 4: Represents a CCD for a patient where only the Vital Signs are Level 3 and Family History is level 2.
I am working on the medications section next, which is perhaps the most complex of the sections to generate, and will post more samples once this is completed. All documents passed the NIST validation tool (when they were originally generated).
Cheers
-Justin
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.