Apologies for the delayed reply, I was stuck trying to fix ETL packages all day. A boring albeit insightful adventure into de-identification and data warehousing
…
I’m not sure what the question is, but I will type a lengthy reply anyways, hoping to hit the mark
J
A element is an ActRelationship which is used in the RIM to link two instances of Act (Acts in the generic RIM sense) together. So you may see
linking an a clinical statement with observations, or sections to sub sections, observations to sub-observations, etc. Hannes is right, the semantics of will change based on context, which isn’t too difficult to handle, just something to keep in
mind.
Additionally, keep an eye on moodCode. I’m not sure about APS and APHP but in CCDA and CCD moodCode changes the semantic meaning of an entry. For example, a
substanceAdministration with moodCode=’EVN’ would mean something did happen (i.e. a substance was administered) versus a moodCode=’INT’ which means there is an intent to do something (i.e. I intend for a substance to be administered), versus moodCode=’RQO’
which represents a request to perform the act. Typically the template will restrict these values and explain the semantics, however it might change where you import the data into your internal data model.
We have implemented (here at Mohawk) some CDA stuff (XPHR and a proprietary set of templates for a commercial PHR vendor) into the OSCAR EMR. I’m not familiar
with the APHP or APS templates, so I’m not sure how useful the next bit of implementation experience will be
J.
We designed the import of data based on the section/entry level using the templateId to construct an appropriate “parser” implementation. Basically grab the
templateId and construct an appropriate parser that handled that particular type of data and let the “parser” do the construction of an appropriate data model object before being persisted. For example, when the software encountered a section with template
id “1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2” (coded vital signs), it constructs a vital signs importer (actually a factory handles this bit). The CodedVitalSignsImporter would then be responsible to translating the CDA stuff from that section context into the internal
representation of the software. Depending on the import procedure it might just grab the text (eyeball to eyeball interoperability) or it would import data from entries (again iterating and constructing relevant parsers). Coded vital signs could contain entries
with template id 1.3.6.1.4.1.19376.1.5.3.1.4.5 (Problem Observation) which would create an interpreter for that type of data (within the context of CodedVitalSigns).
This was (and still is) the grand design for importing data into the EMR. We ran into a bit of a snag with data fidelity and ended up implementing Document
Import rather than Discrete Data Import for the time being (the project is still under active development). I’ve also not had time to be debriefed on the “as-built” to see the delta of changes but from my understanding the implementation is very close to this
design.
···
From: Derek Ritz (ecGroup) [mailto:derek.ritz@ecgroupinc.com]
Sent: Tuesday, April 08, 2014 12:00 PM
To: ‘Suranga Kasthurirathne’; ops_djritz@hotmail.com; Fyfe, Justin
Cc: ‘Ryan Crichton’; ‘Hannes Venter’; ‘Jeremy Keiper’; openhie-shr@googlegroups.com
Subject: RE: Sample CDA document being used for initial SHR development work
Hi all.
I’m inviting Justin Fyfe to give us a bit of insight into this. I worry that we’re hampered by our learning curve with the HL7v3 RIM. Hopefully
Justin can help us with some quick advice.
DJ
**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: Suranga Kasthurirathne [mailto:surangak@openmrs.org]
Sent: Monday, April 7, 2014 11:54 PM
To: ops_djritz@hotmail.com
Cc: Ryan Crichton; Hannes Venter; Derek Ritz, (ecGroup); Jeremy Keiper;
openhie-shr@googlegroups.com
Subject: Re: Sample CDA document being used for initial SHR development work
Hi all,
I may have miscommunicated some of my intentions in my previous email.
There are several levels of nested tags in the APHP CDA, and I had not fully explained what I had intended.
Basically, my parser code runs as follows -
for (Section section : cd.getAllSections()) {
Encounter e = new Encounter();
}
So basically, a is an encounter, and any tags within a section becomes an OpenMRS observation grouped under that encounter.
@Hannes, I saw your comment that a section did not represent an encounter, so i’m interested in your take on how you would handle this.
So (as far as what i’ve done to date) is as follows : the structure of the CDA, as mapped to OpenMRS, would be -
:
<templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.13.2.1'/>
<!-- Required Chief Complaint Section content -->
<observation classCode="OBS" moodCode="EVN"> <!-- this is obs no. 01 -->
</observation>
</component>
<observation classCode="OBS" moodCode="EVN"> <!-- this is obs no. 02 -->
</observation>
</component>
</section>
Here, everything highlighted in yellow is an encounter, and the green sections are individual obs. I was under the impression that there would be multiple tags (as highlighted in red) per CDA, but I see that
this wont be the case, at least for the APHP document ?
Best regards,
Suranga
On Mon, Apr 7, 2014 at 4:29 PM,
ops_djritz@hotmail.com ops_djritz@hotmail.com wrote:
Hi all.
Ryan, I agree that those are the right priorities.
DJ
Sent from my Mobile Phone.
-----Original message-----
From:Ryan Crichton ryan@jembi.org
To: Hannes Venter hannes@jembi.org**
Cc:** Suranga Kasthurirathne surangak@openmrs.org, “Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com, Jeremy Keiper <jeremy@openmrs.org >,
“openhie-shr@googlegroups.com” openhie-shr@googlegroups.com**
Sent:** 2014 Apr, Mon, 7 11:58:33 GMT+00:00
**
Subject:** Re: Sample CDA document being used for initial SHR development work
Hey all,
@Suranga, it sounds like you are now making good progress 
@Hannes, thanks for the detailed response. In terms of your last question, I think that is really a question of maturity. I definitely think it would be useful to be able to parse an APS for another health systems however
I don’t think that is our primary goal for now. What I’m thinking is that we should primarily focus on the following (in order):
-
Parse and discretely store an APHP document in the SHR.
-
Enable the SHR to generate a (virtual) APS document from the discrete data to return to interested systems.
Those seems to create some well defined goals for us. What do others think about this?
Cheers,
Ryan
On Mon, Apr 7, 2014 at 10:56 AM, Hannes Venter hannes@jembi.org wrote:
Hi Guys,
So doesn’t denote an encounter. It’s an association class, so it can mean different things depending on the context.
E.g. a component encapsulates the entire body, components encapsulate different sections in the body, etc.
So I’m sure we’ll have multiple components per CDA regardless of the encounter(s).
I think it depends on the profile type (and how we use it ) as to whether a document can contain multiple encounters.
The APHP document would be one encounter (as it’s captured during an initial visit), but things get a bit more complicated with the APS,
which could contain multiple encounters since it encapsulates a Mother’s entire care episode.
But of course that doesn’t mean we have to capture x encounters per transaction from the PoC, I agree with Derek that we should send one CDA per encounter [from the PoC].
A summary can then be built from the individual encounters.
I guess the question then is do we want to be able to parse a complete APS with multiple encounters in the SHR?
(one possible use-case could be the transfer of a patient’s complete record from another health system…)
What do you guys think?
Cheers
Hannes
PS Suranga, sorry I only now saw your earlier email: Please note that a section is not equivalent to an encounter. It’s merely a grouping; e.g. “medications”, “estimated due dates”, …
On 7 April 2014 05:34, Suranga Kasthurirathne surangak@openmrs.org wrote:
Hi Guys,
Hmm… so this confuses me a bit.
Do you mean to say that we don’t need to support multiple encounters per CDA document at this stage of development work, or that we don’t need to consider multiple encounters per CDA at any stage whatsoever ?
Since I had believed that the contents of one tag equaled one encounter, does this mean that each CDA document that e receive will contain only a single tag each ?
On Sat, Apr 5, 2014 at 8:05 AM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
Thanks, Suranga, for the update and the good news.
J
One small, but important, note: I don’t think that one CDA will contain multiple encounters.
We will, I believe, be sending one CDA per encounter (as we are, today, sending one message per encounter).
Warmest regards,
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: Suranga Kasthurirathne [mailto:surangak@openmrs.org]
Sent: Friday, April 4, 2014 3:47 PM
To: Ryan Crichton
Cc: Hannes Venter; Jeremy Keiper; Derek Ritz, (ecGroup);
openhie-shr@googlegroups.com
Subject: Re: Sample CDA document being used for initial SHR development work
Hi Guys,
A short update on what i’m planning to do in terms of upgrading this CDA document.
-
The document which I have at this point is successfully parsed by the MDHT API. I don’t think that its undergoing a very stringent validation, but at least
it means that we’re not doing anything majorly wrong.
-
I tried validating the document using the online validation tool (http://cdatools.org/validation ).
This produced 9 errors and assorted warnings. I will be trying to resolve these over the next few days.
-
Looking at the ’ Sample Antepartum History and Physical Document’ found
at (http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.16.1.1 ), I note that
there are a number of sections which are specifically needed for each CDA type.
So based on this link, each CDA type NEEDS to have each of these segments, and I’ll be adding them onto my sample as
well.
And as I see it, each section is equivalent to one encounter. So basically, one CDA document will be represented by multiple
encounters. So looking ahead, i’m thinking that we will have to go ahead with what we discussed during the previous call, and have one visit type (and not encounter type) to represent a single CDA.
Thanks and best regards,
Suranga
On Thu, Apr 3, 2014 at 3:16 AM, Ryan Crichton ryan@jembi.org wrote:
Great, thanks Suranga.
One other thing that may be of use are the IHE content module pages on the IHE wiki contain a schematron definition (http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.1.16.1.1 ).
These can be used to validate that the CDA document conforms to that Antepartum History and Physical profile.
Cheers,
Ryan
On Thu, Apr 3, 2014 at 5:41 AM, Suranga Kasthurirathne surangak@openmrs.org wrote:
Hi,
As per our discussion during yesterday’s call, i’ve posted the initial CDA sample document (which i’m using at this point)
here.
Note that this is a very very basic and early version. I will try to update this into a valid Aphp document as I become more and more familiar with it.
Best regards,
Suranga
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
Hannes Venter
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile:
+27 73 276 2848 | Office:
+27 21 701 0939 | Skype: venter.johannes
E-mail:
hannes@jembi.org
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
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.
) as to whether a document can contain multiple encounters.