Sample CCDA documents have missing information
Sairam Sivaswami
I had a look at the CCDA samples that are provided on the TTT homepage. What I see is as below
1) The CCDA_Ambulatory.xml doesn't have the section for "componentOf"
This section should have elements as below
componentOf
|-encompassingEncounter
|-responsibleParty (Provider Name and Office Contact Information)
|-encounterParticipants (Care Team Members)
2) The CCDA_Inpatient.xml has a section fro "componentOf" which is good, see the details below
<componentOf>
<encompassingEncounter>
<id extension="1" root="2.16.840.1.113883.4.6"/>
<code code="233604007" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"
displayName="Pnuemonia"/>
<effectiveTime>
<low value="20120806"/>
<high value="20120813"/>
</effectiveTime>
<responsibleParty>
<assignedEntity>
<id root="2.16.840.1.113883.4.6"/>
<assignedPerson>
<name>
<prefix>Dr</prefix>
<given>Bob</given>
<family>Administrator</family>
</name>
</assignedPerson>
</assignedEntity>
</responsibleParty>
<location>
<healthCareFacility>
<id root="2.16.840.1.113883.4.6"/>
</healthCareFacility>
</location>
</encompassingEncounter>
</componentOf>
However if we look at the required selections we need to have encompassingEncounter/encounterParticipants as below
componentOf
|-encompassingEncounter
|-encounterParticipants (Care Team Members)
And also to be more specific we need the location to be populated with the Visit Location as below.
<name>XYZ Hospital</name>
<addr>
<streetAddressLine>1 Hospital Dr</streetAddressLine>
<city>Portland</city>
<state>OR</state>
<postalCode>97005</postalCode>
<country>US</country>
</addr>
I hope these documents are provided as a sample that people could use as a template to create their CCDA's for MU certification?
If it is, then it would be good to have these documents updated as they have missing elements which the S&I Framework provided for MU2 certification.
Regards,
Sairam
Andrew McCaffrey
Hello,
Thanks for looking over the sample documents available from the TTT site.
In response to question 1: In our last updated to the sample C-CDAs, we
removed the information about Dr. Seven from encompassingEncounter (from
the In-Patient document). The reason for this removal was because the
information was a duplication of the material already provided in the
documentationOf serviceEvent (Dr. Seven is listed in that location as
the "PP", Primary Care Provider). In the ambulatory scenario sample
data, there is likely no encompassingEncounter, so that element was
removed (which made the componentOf element superfluous so it was also
removed).
Our preference is to not duplicate data for reasons of consistency
during maintenance. We have not yet found compelling evidence that the
data in question can only appear in one place or the other. A receiving
application will presumably have to look at both a serviceEvent and an
encompassingEncounter. An application that does not look in both will
potentially be overlooking information.
In response to question 2: Could you elaborate on what you mean by
"required sections"? encounterParticipant is an optional element in the
schema. In Consolidated CDA specification, the optionality is listed as
a MAY on that element. Am I overlooking something?
We agree with the statement that anyone should be able to use these
samples as templates, but please realize that there are only two samples
and they are limited in scope. Anyone looking for in-depth knowledge
should also consult other available samples (including the work
currently being done by HL7's Structure Documents group) and documents.
Thanks again for looking over these samples.
On 03/31/2014 06:43 PM, Sairam Sivaswami wrote:
> Hi,
> I had a look at the CCDA samples that are provided on the TTT homepage.
> What I see is as below
>
> 1) The CCDA_Ambulatory.xml
> doesn't have the section for "*componentOf*"
> componentOf
> |-encompassingEncounter
> |-responsibleParty (Provider Name and Office Contact Information)
> |-encounterParticipants (Care Team Members)
>
>
> You received this message because you are subscribed to the Google
> Groups "Transport Testing Tool" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to transport-testing...@googlegroups.com
> <mailto:transport-testing...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
--
Andrew McCaffrey
andrew.m...@nist.gov
----
The words above do not necessarily reflect the opinions of my employers
or any organization I may be associated with. In fact, by the time you
read them, they may not even reflect my own opinions anymore.
----
Any mention of commercial products within NIST web pages or email is for
information only; it does not imply recommendation or endorsement by NIST.
Sairam Sivaswami
Thanks for your reply. I think there is a misinterpretation of these sections.
If I go through the MU2_Data_Set_V6 from the link http://wiki.siframework.org/file/detail/MU2_Data_Set_v6.xlsx
we see on the Ambulatory or Inpatient Summary the requirement is as below
| Ambulatory or Inpatient Summary Data Requirements | ||||
| C-CDA Template (entries required where vocabulary is specified by MU2) |
MU2
Data Elements (blue indicates Common MU Data Set) |
VDT Ambulatory Summary | VDT Inpatient Summary | Vocabulary |
| C-CDA General Header Template | ||||
| recordTarget/patientRole | ||||
| patient/name | Patient Name | X | X | |
| patient/administrativeGenderCode | Patient Sex | X | X | |
| patient/birthTime | Patient Date of Birth | X | X | |
| patient/raceCode | Patient Race | X | X | OMB |
| patient/ethnicGroupCode | Patient Ethnicity | X | X | OMB |
| patient/languageCommunication | Patient Preferred Language | X | X | ISO 639-2 alpha-3 |
| componentOf | ||||
| encompassingEncounter/responsibleParty | Provider Name and Office Contact Information | X | ||
| encompassingEncounter/encounterParticipants | Care Team Members | X | X | |
| encompassingEncounter/effectiveTime | Admission and Discharge Dates | X | ||
| Date of Visit | ||||
| encompassingEncounter/location | Admission and Discharge Location | X | ||
| Visit Location | ||||
| documentationOf/serviceEvent | ||||
| assignedEntity/assignedPerson | Care Team Members | X | X | |
Which suggests we need Care Team Members captured in both componentOf/encompassingEncounter/encounterParticipants and documentationOf/assignedEntity/assignedPerson for both Ambulatory and InPatient Summary.
Also the details encompassingEncounter/effectiveTime & encompassingEncounter/location has to be captured in the InPatient Summary, which probably I was not clear enough in my previous post in case (2)
To cross check I looked into the S&I Framework - Companion_Guide_to_CCDA_for_MU2.
What I see in that is as below
|
documentationOf/serviceEvent *if a service event is detailed in document |
|
SHALL effectiveTime [date of visit or hospitalization] |
|
SHALL low [admission date] |
|
SHOULD high [discharge date] |
|
SHOULD performer [care team member or provider performing the service event] |
|
SHALL typeCode |
|
MAY functionCode |
|
SHALL assignedEntity |
|
SHALL id |
|
SHOULD code |
|
SHALL addr [care team member or provider contact information] |
|
SHALL telecom [care team member or provider contact information] |
|
SHALL assignedPerson |
|
SHALL name [care team member or provider name] |
|
componentOf/encompassingEncounter *if an encounter is detailed in document |
|
SHALL id |
|
SHALL effectiveTime [date and time of visit or hospitalization] |
|
SHOULD low [admission date] |
|
SHOULD high [discharge date] |
|
SHALL location |
|
SHALL healthcareFacility |
|
SHALL id |
|
SHOULD code |
|
SHOULD location [location of visit or hospitalization] |
|
SHOULD name |
|
SHOULD addr |
|
SHOULD serviceProviderOrganization |
|
SHALL id |
|
SHOULD name |
|
SHOULD telecom |
|
SHOULD addr |
|
SHOULD standardIndustryClassCode |
|
MAY code |
|
SHALL responsibleParty [care team member or provider responsible for encounter] |
|
SHALL assignedEntity |
|
SHALL assignedPerson or representedOrganization |
|
SHALL name [care team member or provider name] |
|
SHALL addr [care team member or provider contact information] |
|
SHOULD telecom [care team member or provider contact information] |
|
SHOULD encounterParticipant [care team member participating in the encounter] |
|
SHALL typeCode |
|
SHALL effectiveTime |
|
SHALL assignedEntity |
|
SHALL assignedPerson or representedOrganization |
|
SHALL name [care team member or provider name] |
|
SHOULD addr [care team member or provider contact information] |
|
SHOULD telecom [care team member or provider contact information] |
I don't think a MAY is listed for any of these elements. Which suggests to me that the details has to be captured as both places in the xml document, else your CCDA would fail visual validation of the xml's if you undertake certification for View, Download, Transmit (E1)
Let me know if I am still unclear or if I have misinterpreted the documents or if its something that you need to fix.
Regards,
Sairam
> an email to transport-testing-tool+unsub...@googlegroups.com
> <mailto:transport-testing-tool+unsubscribe@googlegroups.com>.
Brian Weiss (CDA PRO)
Andrew and Sairam,
The use of componentOf/encompassingEncounter in a C-CDA CCD (and this ambulatory example is a CCD) is indeed optional.
However, it’s not the case that “In the ambulatory scenario sample data, there is likely no encompassingEncounter”. The key factor here is whether there is a well defined "primary encounter" that is reflected in the document, or not.
Here are some relevant explanatory articles:
· Use of encompassingEncounter in MU2 C-CDA documents (http://www.cdapro.com/know/26197)
· Should there be an encompassingEncounter in a C-CDA CCD? (http://www.cdapro.com/know/26193)
As best I can tell, this particular CCD is a summary following a specific encounter (there is only one encounter in the body, and it is also implied in the serviceEvent), and thus componentOf/encompassingEncounter should be there.
There is redundancy here (not only between serviceEvent and encompassingEncounter, also the encounter in the Body), but both the S&I Companion Guide and the C-CDA IG appear to advocate this redundancy.
If a CCD (or non-specific-document-template MU2 document) was summarizing a period of time covering many encounters and none was “primary” (e.g. just an overall summary of healthcare over a long time-range that covered multiple encounters) – then it would be appropriate to leave out componentOf/encompassingEncounter of the Header and instead list all the encounters only in the Body.
Brian Weiss
> an email to transport-testing...@googlegroups.com
> <mailto:transport-testing...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
--
Andrew McCaffrey
andrew.m...@nist.gov
----
The words above do not necessarily reflect the opinions of my employers
or any organization I may be associated with. In fact, by the time you
read them, they may not even reflect my own opinions anymore.
----
Any mention of commercial products within NIST web pages or email is for
information only; it does not imply recommendation or endorsement by NIST.
--
You received this message because you are subscribed to the Google Groups "Transport Testing Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transport-testing...@googlegroups.com.
Sairam Sivaswami
Thanks a lot for your post and the reference links that you have posted. It give me a clear understanding of the scenarios and the corresponding elements to be used.
Thanks again
Regards,
Sairam
> an email to transport-testing-tool+unsub...@googlegroups.com
> <mailto:transport-testing-tool+unsubscribe@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
--
Andrew McCaffrey
andrew.m...@nist.gov
----
The words above do not necessarily reflect the opinions of my employers
or any organization I may be associated with. In fact, by the time you
read them, they may not even reflect my own opinions anymore.
----
Any mention of commercial products within NIST web pages or email is for
information only; it does not imply recommendation or endorsement by NIST.
--
You received this message because you are subscribed to the Google Groups "Transport Testing Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transport-testing-tool+unsub...@googlegroups.com.
Andrew McCaffrey
Hi Brian and Sairam,
I think there is ambiguity concerning the primary encounter /
encompassing encounter that probably historically goes back to different
paths that in-patient and ambulatory took when it comes to encoding this
information. One can look at the current C-CDA CCD (which has its
history in the C32, and before that the CCD v1.0, and before that the
CCR) and its use of documentationOf/serviceEvent.
This historical path is why we choose to use a
componentOf/encompassingEncounter in the Inpatient example, but not in
the Ambulatory.
Our feeling was that a receiving application will need to look in both
places for this information. An application only expecting to find
information in one location would be lacking.
We agree that a requirement that the Care Team's members/information be
listed. But our reasoning is that there are several legitimate
locations where that data could be placed:
1) documentationOf/serviceEvent/assignedEntity/assignedPerson, or
2) componentOf/encompassingEncounter/encounterParticipants, or
3) an optional Encounter section, or
4) possibly even scattered in various sections as the "performer" of
a listed event.
We couldn't find a single, unambiguous place where this information must
always exist. We couldn't find reason to favor one of these locations
be chosen over the others for the Care Team content. If a best
practices document (or a future release of Consolidated CDA) is
published, this would of course change. But in the interim we think a
reading/receiving application would need to look for such information in
potentially multiple places.
Another historical note: in some past specifications (CCD v1.0 and HITSP
C32) our understanding was that there was a strong suggestion (but not a
requirement!) that Care Team information (id, name, title, address,
phone, fax and other contact information) be located in one location.
Then those care team members could be referenced from other locations in
the document just by their id (meaning that the complete detailed
information would not have to be listed multiple times).
Although the wording in MU2 is ambiguous, we do not agree that
redundant, duplicated information SHOULD appear in more than one
location. From our point-of-view, this is for maintenance reasons. If
we needed to change a phone number, we're less likely to make a mistake
if that change only happens in one place and is simply referenced.
-Andrew
On 04/02/2014 07:12 AM, Brian Weiss (CDA PRO) wrote:
> Andrew and Sairam,
>
> The use of componentOf/encompassingEncounter in a C-CDA CCD (and this
> ambulatory example is a CCD) is indeed optional.
>
> However, it’s not the case that “In the ambulatory scenario sample data,
> there is likely no encompassingEncounter”. The key factor here is
> whether there is a well defined "primary encounter" that is reflected in
> the document, or not.
>
> Here are some relevant explanatory articles:
>
> (http://www.cdapro.com/know/26197)
>
> ·*/Should there be an encompassingEncounter in a C-CDA CCD?/*
>
> As best I can tell, this particular CCD is a summary following a
> specific encounter (there is only one encounter in the body, and it is
> componentOf/encompassingEncounter should be there._*
> There is redundancy here (not only between serviceEvent and
> encompassingEncounter, also the encounter in the Body), but both the S&I
> Companion Guide and the C-CDA IG appear to advocate this redundancy.
>
> If a CCD (or non-specific-document-template MU2 document) was
> summarizing a period of time covering many encounters and none was
> “primary” (e.g. just an overall summary of healthcare over a long
> time-range that covered multiple encounters) – then it would be
> appropriate to leave out componentOf/encompassingEncounter of the Header
> and instead list all the encounters only in the Body.
>
>
> logo_201x75
>
> www.cdapro.com <http://www.cdapro.com/>
>
> *From:* transport-t...@googlegroups.com
> [mailto:transport-t...@googlegroups.com] *On Behalf Of *Sairam
> Sivaswami
> *Sent:* Wednesday, April 02, 2014 06:17
> *To:* transport-t...@googlegroups.com
> *Cc:* l...@nist.gov; LenG...@aol.com
> *Subject:* Re: Sample CCDA documents have missing information
> Hi Andrew,
> Thanks for your reply. I think there is a misinterpretation of these
> sections.
> If I go through the MU2_Data_Set_V6 from the link
> http://wiki.siframework.org/file/detail/MU2_Data_Set_v6.xlsx
> we see on the Ambulatory or Inpatient Summary the requirement is as below
>
>
> *C-CDA Template
> */(entries required where vocabulary is specified by MU2)/**
>
>
>
> *MU2 Data Elements
> */(blue indicates
> Common MU Data Set)/**
>
>
>
> *VDT Ambulatory Summary*
>
>
>
> *VDT Inpatient Summary*
>
>
>
> *Vocabulary*
>
> *C-CDA General Header Template*
>
>
>
> **
>
>
>
>
>
>
>
> *recordTarget/patientRole***
>
>
>
>
>
>
>
>
> encompassingEncounter/responsibleParty
>
>
>
> Provider Name and Office Contact Information
>
>
>
> X
>
>
>
>
>
> encompassingEncounter/encounterParticipants
>
>
>
> Care Team Members
>
>
>
> X
>
>
>
> X
>
>
>
> encompassingEncounter/effectiveTime
>
>
>
> Admission and Discharge Dates
>
>
>
>
>
> X
>
>
>
> Date of Visit
>
>
>
>
>
>
>
> encompassingEncounter/location
>
>
>
> Admission and Discharge Location
>
>
>
>
>
> X
>
>
>
> Visit Location
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> assignedEntity/assignedPerson
>
>
>
> Care Team Members
>
>
>
> X
>
>
>
> X
>
>
>
>
> Which suggests we need Care Team Members captured in both
> componentOf/encompassingEncounter/encounterParticipants and
> documentationOf/assignedEntity/assignedPerson for both Ambulatory and
> InPatient Summary.
>
> Also the details encompassingEncounter/effectiveTime &
> encompassingEncounter/location has to be captured in the InPatient
> Summary, which probably I was not clear enough in my previous post in
> case (2)
>
> To cross check I looked into the S&I Framework -
> Companion_Guide_to_CCDA_for_MU2.
> What I see in that is as below
>
>
> SHALL*effectiveTime *[date of visit or hospitalization]
>
> SHALL*low *[admission date]
>
> SHOULD *high* [discharge date]
>
> SHOULD*performer *[care team member or provider performing the service
> event]
>
> SHALL *typeCode*
>
> MAY*functionCode*
>
> SHALL*assignedEntity*
>
> SHALL*id*
>
> SHOULD*code*
>
> /SHALL*addr */[care team member or provider contact information]
>
> /SHALL*telecom*/*//*[care team member or provider contact information]
>
> /SHALL*assignedPerson*/
>
> /SHALL *name */[care team member or provider name]
>
> *componentOf/encompassingEncounter */*if an encounter is detailed in
> document/
>
> SHALL*id*
>
> SHALL*effectiveTime *[date and time of visit or hospitalization]
>
> /SHOULD*low */[admission date]
>
> /SHOULD *high */[discharge date]
>
> /SHALL*location */
>
> /SHALL*healthcareFacility */
>
> /SHALL*id*/
>
> /SHOULD*code*/
>
> /SHOULD*location */[location of visit or hospitalization]
>
> /SHOULD*name */
>
> /SHOULD*addr */
>
> /SHOULD*serviceProviderOrganization */
>
> /SHALL*id*/
>
> /SHOULD*name*/
>
> /SHOULD*telecom*/
>
> /SHOULD*addr*/
>
> /SHOULD*standardIndustryClassCode*/
>
> /MAY*code*/
>
> /SHALL*responsibleParty */[care team member or provider responsible for
> encounter]
>
> /SHALL*assignedEntity*/
>
> /SHALL*assignedPerson or representedOrganization*/
>
> /SHALL*name */[care team member or provider name]
>
> /SHALL*addr */[care team member or provider contact information]
>
> /SHOULD*telecom */[care team member or provider contact information]
>
> /SHOULD*encounterParticipant*/*//*[care team member participating in the
> encounter]
>
> /SHALL*typeCode*/
>
> /SHALL*effectiveTime*/
>
> /SHALL*assignedEntity*/
>
> /SHALL*assignedPerson or representedOrganization*/
>
> /SHALL *name */[care team member or provider name]
>
> /SHOULD*addr */[care team member or provider contact information]
>
> /SHOULD *telecom */[care team member or provider contact information]
>
> I don't think a MAY is listed for any of these elements. Which suggests
> to me that the details has to be captured as both places in the xml
> document, else your CCDA would fail visual validation of the xml's if
> you undertake certification for View, Download, Transmit (E1)
>
>
> Let me know if I am still unclear or if I have misinterpreted the
> documents or if its something that you need to fix.
>
>
> Regards,
> Sairam
>
>
>
> On Wednesday, 2 April 2014 09:56:28 UTC+13, andrew.m...@nist.gov
> > <mailto:transport-testing...@googlegroups.com
> <javascript:>>.
> andrew.m...@nist.gov <javascript:>
> The words above do not necessarily reflect the opinions of my employers
> or any organization I may be associated with. In fact, by the time you
> read them, they may not even reflect my own opinions anymore.
> ----
> Any mention of commercial products within NIST web pages or email is
> for
> information only; it does not imply recommendation or endorsement by
> NIST.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Transport Testing Tool" group.
> To unsubscribe from this group and stop receiving emails from it, send
Lisa Nelson
Andrew wrote:
"Another historical note: in some past specifications (CCD v1.0 and HITSP
C32) our understanding was that there was a strong suggestion (but not a
requirement!) that Care Team information (id, name, title, address, phone, fax and other contact information) be located in one location.
Then those care team members could be referenced from other locations in the document just by their id (meaning that the complete detailed information would not have to be listed multiple times)."
Lisa
Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaR...@cox.net
-----Original Message-----
From: transport-t...@googlegroups.com [mailto:transport-t...@googlegroups.com] On Behalf Of Andrew McCaffrey
Sent: Wednesday, April 02, 2014 4:01 PM
To: transport-t...@googlegroups.com
Cc: l...@nist.gov; LenG...@aol.com
Subject: Re: Sample CCDA documents have missing information
I think there is ambiguity concerning the primary encounter / encompassing encounter that probably historically goes back to different paths that in-patient and ambulatory took when it comes to encoding this information. One can look at the current C-CDA CCD (which has its history in the C32, and before that the CCD v1.0, and before that the
CCR) and its use of documentationOf/serviceEvent.
This historical path is why we choose to use a componentOf/encompassingEncounter in the Inpatient example, but not in the Ambulatory.
Our feeling was that a receiving application will need to look in both places for this information. An application only expecting to find information in one location would be lacking.
We agree that a requirement that the Care Team's members/information be listed. But our reasoning is that there are several legitimate locations where that data could be placed:
1) documentationOf/serviceEvent/assignedEntity/assignedPerson, or
2) componentOf/encompassingEncounter/encounterParticipants, or
3) an optional Encounter section, or
4) possibly even scattered in various sections as the "performer" of a listed event.
We couldn't find a single, unambiguous place where this information must always exist. We couldn't find reason to favor one of these locations be chosen over the others for the Care Team content. If a best practices document (or a future release of Consolidated CDA) is published, this would of course change. But in the interim we think a reading/receiving application would need to look for such information in potentially multiple places.
Another historical note: in some past specifications (CCD v1.0 and HITSP
C32) our understanding was that there was a strong suggestion (but not a
requirement!) that Care Team information (id, name, title, address, phone, fax and other contact information) be located in one location.
Then those care team members could be referenced from other locations in the document just by their id (meaning that the complete detailed information would not have to be listed multiple times).
Although the wording in MU2 is ambiguous, we do not agree that redundant, duplicated information SHOULD appear in more than one location. From our point-of-view, this is for maintenance reasons. If we needed to change a phone number, we're less likely to make a mistake if that change only happens in one place and is simply referenced.
-Andrew
On 04/02/2014 07:12 AM, Brian Weiss (CDA PRO) wrote:
>
> The use of componentOf/encompassingEncounter in a C-CDA CCD (and this
> ambulatory example is a CCD) is indeed optional.
>
> However, it’s not the case that “In the ambulatory scenario sample
> data, there is likely no encompassingEncounter”. The key factor here
> is whether there is a well defined "primary encounter" that is
> reflected in the document, or not.
>
> Here are some relevant explanatory articles:
>
> (http://www.cdapro.com/know/26197)
>
> ·*/Should there be an encompassingEncounter in a C-CDA CCD?/*
>
> As best I can tell, this particular CCD is a summary following a
> specific encounter (there is only one encounter in the body, and it is
> componentOf/encompassingEncounter should be there._*
>
> encompassingEncounter, also the encounter in the Body), but both the
> S&I Companion Guide and the C-CDA IG appear to advocate this redundancy.
>
> If a CCD (or non-specific-document-template MU2 document) was
> summarizing a period of time covering many encounters and none was
> “primary” (e.g. just an overall summary of healthcare over a long
> time-range that covered multiple encounters) – then it would be
> appropriate to leave out componentOf/encompassingEncounter of the
> Header and instead list all the encounters only in the Body.
>
>
> logo_201x75
>
> www.cdapro.com <http://www.cdapro.com/>
>
> *From:* transport-t...@googlegroups.com
> [mailto:transport-t...@googlegroups.com] *On Behalf Of *Sairam
> Sivaswami
> *Sent:* Wednesday, April 02, 2014 06:17
> *To:* transport-t...@googlegroups.com
> *Cc:* l...@nist.gov; LenG...@aol.com
> Hi Andrew,
> Thanks for your reply. I think there is a misinterpretation of these
> sections.
> If I go through the MU2_Data_Set_V6 from the link
> http://wiki.siframework.org/file/detail/MU2_Data_Set_v6.xlsx
> we see on the Ambulatory or Inpatient Summary the requirement is as
> below
>
>
> *C-CDA Template
> */(entries required where vocabulary is specified by MU2)/**
>
>
>
> *MU2 Data Elements
> */(blue indicates
> Common MU Data Set)/**
>
>
>
> *VDT Ambulatory Summary*
>
>
>
> *VDT Inpatient Summary*
>
>
>
> *Vocabulary*
>
> *C-CDA General Header Template*
>
>
>
> **
>
>
>
>
>
>
>
> *recordTarget/patientRole***
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> encompassingEncounter/responsibleParty
>
>
>
> Provider Name and Office Contact Information
>
>
>
> X
>
>
>
>
>
> encompassingEncounter/encounterParticipants
>
>
>
> Care Team Members
>
>
>
> X
>
>
>
> X
>
>
>
> encompassingEncounter/effectiveTime
>
>
>
> Admission and Discharge Dates
>
>
>
>
>
> X
>
>
>
> Date of Visit
>
>
>
>
>
>
>
> encompassingEncounter/location
>
>
>
> Admission and Discharge Location
>
>
>
>
>
> X
>
>
>
> Visit Location
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> assignedEntity/assignedPerson
>
>
>
> Care Team Members
>
>
>
> X
>
>
>
> X
>
>
>
>
> Which suggests we need Care Team Members captured in both
> componentOf/encompassingEncounter/encounterParticipants and
> documentationOf/assignedEntity/assignedPerson for both Ambulatory and
> InPatient Summary.
>
> Also the details encompassingEncounter/effectiveTime &
> encompassingEncounter/location has to be captured in the InPatient
> Summary, which probably I was not clear enough in my previous post in
> case (2)
>
> To cross check I looked into the S&I Framework -
> Companion_Guide_to_CCDA_for_MU2.
> What I see in that is as below
>
> document/
>
> SHALL*effectiveTime *[date of visit or hospitalization]
>
> SHALL*low *[admission date]
>
> SHOULD *high* [discharge date]
>
> event]
>
> for encounter]
>
> /SHALL*assignedEntity*/
>
> /SHALL*assignedPerson or representedOrganization*/
>
> /SHALL*name */[care team member or provider name]
>
> /SHALL*addr */[care team member or provider contact information]
>
> /SHOULD*telecom */[care team member or provider contact information]
>
> /SHOULD*encounterParticipant*/*//*[care team member participating in
> the encounter]
>
>
> /SHALL*effectiveTime*/
>
> /SHALL*assignedEntity*/
>
> /SHALL*assignedPerson or representedOrganization*/
>
>
> /SHOULD*addr */[care team member or provider contact information]
>
> /SHOULD *telecom */[care team member or provider contact information]
>
> I don't think a MAY is listed for any of these elements. Which
> suggests to me that the details has to be captured as both places in
> the xml document, else your CCDA would fail visual validation of the
> xml's if you undertake certification for View, Download, Transmit (E1)
>
>
> Let me know if I am still unclear or if I have misinterpreted the
> documents or if its something that you need to fix.
>
>
> Regards,
> Sairam
>
>
>
> On Wednesday, 2 April 2014 09:56:28 UTC+13, andrew.m...@nist.gov
> > <mailto:transport-testing...@googlegroups.com
> <javascript:>>.
> andrew.m...@nist.gov <javascript:>
> The words above do not necessarily reflect the opinions of my employers
> or any organization I may be associated with. In fact, by the time you
> read them, they may not even reflect my own opinions anymore.
> ----
> Any mention of commercial products within NIST web pages or email is
> for
> information only; it does not imply recommendation or endorsement by
> NIST.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Transport Testing Tool" group.
> To unsubscribe from this group and stop receiving emails from it, send
Brian Weiss (CDA PRO)
Andrew,
Lots of good points. Agree the redundancy is not good and a "pointer" mechanism would be helpful. Also agree it's ambiguous/challenging in some of the documentation as to when encompassingEncounter and/or serviceEvent are optional and when they are required. BTW, you left off another potential place for care team members to go (participants in the Header - though right now this is guided to as being for "non-clinical supporting participants", Lisa and others feel that's not correct and are trying to have it changed).
But I think most of your arguments are not relevant to what should be driving the creation of this NIST sample right now. You have to very precisely reflect the published documentation – you can’t “do what you feel is best” and ignore what the documentation says. So, let's look at the documentation and see if it supports your approach of "be redundant for inpatient but not for ambulatory - for ambulatory, leave out encompassingEncounter".
1) CDA (4.2.3.5 encompassingEncounter): This optional class represents the setting of the clinical encounter during which the documented act(s) or ServiceEvent occurred… The encounterParticipant participant represents clinicians directly associated with the encounter (e.g. by initiating, terminating, or overseeing it).
2) C-CDA (2.2.11 documentationOf/serviceEvent under 2.2 US Realm General Header): If the document is about a single encounter, the providers associated can be recorded in the componentOf/encompassingEncounter. (2.2.13 componentOf under 2.2 US Realm General Header): In order to represent providers associated with a specific encounter, they are recorded within the encompassingEncounter as participants… In a CCD the encompassingEncounter may be used when documenting a specific encounter and its participants.
3) S&I Companion Guide (3.2.1 Considerations - Care Team Members and Provider Names and Contact Information): In most cases, multiple participants will be the same care team member. For example, a consulting physician may see a patient in a clinical encounter, dictate a note, and legally authenticate the document. In this example, the consulting physician is participating as the encounterParticipant, author, and legalAuthenticator. (Table 4 in that same section): componentOf/
encompassingEncounter/ encounterParticipant: Care team member who participates in the encounter detailed in the document. Examples: PCP, consulting physician, attending physician. (later in that same section): For single encounters, key care team members are still performers of the provision of care captured in the documentationOf/serviceEvent header element while care team members participating in the specific clinical encounter are the encounterParticipants within the componentOf/encompassingEncounter header element.
Note that the S&I Companion Guide explicitly acknowledges (and calls for) the redundancy: (“In most cases, multiple participants will be the same care team member…”).
In “Table 5-7 Sample CCD Participation Scenarios” (again, in that same section) there are two ambulatory examples (and one inpatient). One is a PCP generating a CCD for a PHR (i.e. it’s a broad clinical summary and NOT about a specific encounter) and one is a consulting physician producing a CCD for a PHP (and the patient) about a specific encounter. In the first one, there is no componetOf/encompassingEncounter (because, as noted, there is an Encounters section that captures multiple encounters and associated team members) but in the specific-encounter CCD it states very clearly: “componentOf/encompassingEncounter - Captures the names and contact information of the consulting provider as the responsible party for the clinical encounter and the nurse practitioner as an encounterParticipant”.
I believe everything above is consistent with what I presented in my articles – and, as best I can tell, none of it is consistent with what you have done in the ambulatory sample. The decision to include encompassingEncounter (and, thus, encompassingEncounter/encounterParticipant) is based on whether there is a single primary encounter described in the document or not. It is NOT based on ambulatory vs. inpatient.
Now, you may be right about what it “should be” in the future – I’m not sure, but it doesn’t matter in this context... The requirement here is to create samples that are consisted with the documentation – not to “engineer new approaches”. You are welcome to bring your approach to HL7, the S&I Companion Guide team, etc. and work to get the published documentation changed to match your sample. However, until you do, I think you need to follow the published guidance.
If you think your sample is consistent with the documentation, please explain how it aligns with the texts I noted above and/or others I may have missed. The CCD sample you created describes a single 30 minute encounter as its “provision of care service event”. Where in the CDA, C-CDA, and MU2 (S&I) documentation does it say that leaving out encompassingEncounter in a document like that is what you should do, if the encounter was in an ambulatory setting?
While I appreciate your views on the subject (and agree with many of them), it’s not helpful in this context to explain why redundancy is bad, why we should have a pointer mechanism, what the history was, what your feelings are about where people have to look for information, etc. – this is not a design forum for MU2 C-CDA documents – we’re reviewing an official US government sample that must be properly aligned with the US government’s published guidance (the S&I Companion Guide, which in turn references the HL7 CDA and C-CDA specs). So, let’s limit the discussion to that…
Brian
-----Original Message-----
From: transport-t...@googlegroups.com [mailto:transport-t...@googlegroups.com] On Behalf Of Andrew McCaffrey
Sent: Wednesday, April 02, 2014 23:01
To: transport-t...@googlegroups.com
Cc: l...@nist.gov; LenG...@aol.com
To unsubscribe from this group and stop receiving emails from it, send an email to transport-testing...@googlegroups.com.
Lisa Nelson
All,
I agree that what Brian has documented below is accurate with respect to the function and use of the EncompassingEncounter and ServiceEvent acts and their respective participations. In my opinion, this is a clear and accurate summarization of the standards in place today.
To the point about redundancy, I will be pushing within SDWG and the CDA Examples Task Force to better flesh out how id reference can and should work to address the need to minimize redundancy. Once we get that bit worked out, I predict that the beauty of the RIM’s design for role classes will really begin to jump out at us. Stay tuned!
I would like to make one additional comment that adds a bit of perspective on this. I have had the great pleasure of working with Andrew McCaffrey (The 2010 Winner of Keith Boone’s Motorcycle Guy Award http://motorcycleguy.blogspot.com/2010/01/recognition.html ) for many years through our shared efforts to make the CDA testing at the IHE Connectathon happen. The early NIST validation efforts were miraculous. The specifications were incomplete and imperfect and often a real mess. Forced to “intuit” his way across some of these gaps, Andrew materialized black and white schematron tests out of gray and mirky material. The good news is….our specifications are getting better, so we can point to solid documentation for developing tests. We are even moving toward ways to automate test creation by using new tools that help us craft template designs and offer test scripts as a bi-product. It is great that we are finally arriving at a place where we can shift to greater reliance on the specs, but thank heavens for the personal contributions from people like Andrew who carried us through to this point. And thanks to the new energy emerging to push us toward more maturity in our CDA implementations.
Lisa
Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaR...@cox.net
From: transport-t...@googlegroups.com [mailto:transport-t...@googlegroups.com] On Behalf Of Brian Weiss (CDA PRO)
Sent: Thursday, April 03, 2014 1:49 AM
To: 'Andrew McCaffrey'; transport-t...@googlegroups.com
Cc: l...@nist.gov; LenG...@aol.com
Subject: RE: Sample CCDA documents have missing information
Andrew,
Lots of good points. Agree the redundancy is not good and a "pointer" mechanism would be helpful. Also agree it's ambiguous/challenging in some of the documentation as to when encompassingEncounter and/or serviceEvent are optional and when they are required. BTW, you left off another potential place for care team members to go (participants in the Header - though right now this is guided to as being for "non-clinical supporting participants", Lisa and others feel that's not correct and are trying to have it changed).
But I think most of your arguments are not relevant to what should be driving the creation of this NIST sample right now. You have to very precisely reflect the published documentation – you can’t “do what you feel is best” and ignore what the documentation says. So, let's look at the documentation and see if it supports your approach of "be redundant for inpatient but not for ambulatory - for ambulatory, leave out encompassingEncounter".
1) CDA (4.2.3.5 encompassingEncounter): This optional class represents the setting of the clinical encounter during which the documented act(s) or ServiceEvent occurred… The encounterParticipant participant represents clinicians directly associated with the encounter (e.g. by initiating, terminating, or overseeing it).
2) C-CDA (2.2.11 documentationOf/serviceEvent under 2.2 US Realm General Header): If the document is about a single encounter, the providers associated can be recorded in the componentOf/encompassingEncounter. (2.2.13 componentOf under 2.2 US Realm General Header): In order to represent providers associated with a specific encounter, they are recorded within the encompassingEncounter as participants… In a CCD the encompassingEncounter may be used when documenting a specific encounter and its participants.
3) S&I Companion Guide (3.2.1 Considerations - Care Team Members and Provider Names and Contact Information): In most cases, multiple participants will be the same care team member. For example, a consulting physician may see a patient in a clinical encounter, dictate a note, and legally authenticate the document. In this example, the consulting physician is participating as the encounterParticipant, author, and legalAuthenticator. (Table 4 in that same section): componentOf/
encompassingEncounter/ encounterParticipant: Care team member who participates in the encounter detailed in the document. Examples: PCP, consulting physician, attending physician. (later in that same section): For single encounters, key care team members are still performers of the provision of care captured in the documentationOf/serviceEvent header element while care team members participating in the specific clinical encounter are the encounterParticipants within the componentOf/encompassingEncounter header element.
Note that the S&I Companion Guide explicitly acknowledges (and calls for) the redundancy: (“In most cases, multiple participants will be the same care team member…”).
In “Table 5-7 Sample CCD Participation Scenarios” (again, in that same section) there are two ambulatory examples (and one inpatient). One is a PCP generating a CCD for a PHR (i.e. it’s a broad clinical summary and NOT about a specific encounter) and one is a consulting physician producing a CCD for a PHP (and the patient) about a specific encounter. In the first one, there is no componetOf/encompassingEncounter (because, as noted, there is an Encounters section that captures multiple encounters and associated team members) but in the specific-encounter CCD it states very clearly: “componentOf/encompassingEncounter - Captures the names and contact information of the consulting provider as the responsible party for the clinical encounter and the nurse practitioner as an encounterParticipant”.
I believe everything above is consistent with what I presented in my articles – and, as best I can tell, none of it is consistent with what you have done in the ambulatory sample. The decision to include encompassingEncounter (and, thus, encompassingEncounter/encounterParticipant) is based on whether there is a single primary encounter described in the document or not. It is NOT based on ambulatory vs. inpatient.
Now, you may be right about what it “should be” in the future – I’m not sure, but it doesn’t matter in this context... The requirement here is to create samples that are consisted with the documentation – not to “engineer new approaches”. You are welcome to bring your approach to HL7, the S&I Companion Guide team, etc. and work to get the published documentation changed to match your sample. However, until you do, I think you need to follow the published guidance.
If you think your sample is consistent with the documentation, please explain how it aligns with the texts I noted above and/or others I may have missed. The CCD sample you created describes a single 30 minute encounter as its “provision of care service event”. Where in the CDA, C-CDA, and MU2 (S&I) documentation does it say that leaving out encompassingEncounter in a document like that is what you should do, if the encounter was in an ambulatory setting?
While I appreciate your views on the subject (and agree with many of them), it’s not helpful in this context to explain why redundancy is bad, why we should have a pointer mechanism, what the history was, what your feelings are about where people have to look for information, etc. – this is not a design forum for MU2 C-CDA documents – we’re reviewing an official US government sample that must be properly aligned with the US government’s published guidance (the S&I Companion Guide, which in turn references the HL7 CDA and C-CDA specs). So, let’s limit the discussion to that…
Brian
-----Original Message-----
From: transport-t...@googlegroups.com [mailto:transport-t...@googlegroups.com] On Behalf Of Andrew McCaffrey
Sent: Wednesday, April 02, 2014 23:01
To: transport-t...@googlegroups.com
Cc: l...@nist.gov; LenG...@aol.com
To unsubscribe from this group and stop receiving emails from it, send an email to transport-testing...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transport Testing Tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transport-testing...@googlegroups.com.
Andrew McCaffrey
Brian,
Thanks for the discussion and I hope other people on the list can use
this to further their own understanding (it's certainly prodding/helping
me to think some of these issues through). We seem to have gotten onto
a tangent. Perhaps I haven't been clear in my previous responses so I
want to say a few things at the outset. NIST did not intentionally set
out to “do what [we] feel is best and ignore what the documentation
says”. We did not write samples to reflect what “should be”. You are
correct; the samples (and indeed this mailing list) are not the
appropriate venues for NIST to convey a contrary opinion on what the
specifications should or shouldn't state and we did not wish to do so.
Our intent was to match the MU2 scenarios as closely as possible in
order to give vendors and test labs an idea of what to expect. They
cannot mimic all possible situations.
Let's limit ourselves to this particular instance. The
componentOf/encompassingEncounter is given a MAY conditional in C-CDA
2.2.12. The definition there states: “The encompassing encounter
where there is a single clinical encounter that supports the entire
document, it seems appropriate to put that information here, which is
why we did for the In-Patient sample.
For longitudinal records, it not as clear. In CDA R2, componentOf has
0..1 cardinality. encompassingEncounter is 1..1. If the document
contains several historical pieces of information (previous visits,
previous surgeries, previous reported allergies) then multiple
“encompassing” encounters would exist, but placing multiple pieces of
data in this location is not possible.
Looking at Ambulatory in general, if a longitudinal record could be
encompassed by a single encompassing encounter, then
componentOf/encompassingEncounter would be an appropriate place to
record that. If it can't be encompassed by a single encompassing
encounter, then by CDA R2 those multiple pieces of information cannot be
recorded here. In this particular MU2 sample scenario that we are
discussing, it seemed ambiguous as to whether a single encompassing
encounter was appropriate, so we recorded the information as shown in
the sample XML.
Remember, that our sample is not intended to show all possible
longitudinal Ambulatory possibilities. Certainly one could conceive of
a Ambulatory record that would have only an unambiguous single
encompassingEncounter. And indeed it would be appropriate for the
information in that particular scenario to be recorded in
componentOf/encompassingEncounter. But in this individual case, that
cannot be determined unambiguously.
If MU were to point to a new Implementation Guide or newer specification
(or a best practices paper) that stated something different, then we
would of course update the samples to reflect this change. Until then,
we have to do what the specifications state.
I hope this conveys what our thinking was in determining how to record
information in these two samples.
Thanks,
Andrew
On 04/03/2014 01:49 AM, Brian Weiss (CDA PRO) wrote:
> Andrew,
>
> Lots of good points. Agree the redundancy is not good and a "pointer"
> of the documentation as towhen encompassingEncounter and/or serviceEvent
> are optional and when they are required.BTW,you left off another
> - though right now this is guided to as beingfor "non-clinicalsupporting
> participants", Lisa and others feel that's not correct and are trying to
> have it changed).
>
> be driving the creation ofthisNIST sampleright now. You have to very
> encompassingEncounter".
>
> 1)*_CDA_**(4.2.3.5 encompassingEncounter)*:This optional
> during which the documented act(s) or ServiceEvent
> occurred…The encounterParticipant participant represents
> clinicians directly associated with the encounter (e.g. by
> initiating, terminating, or overseeing it).
>
> US Realm General Header)*:If the document is about a single
> 2.2 US Realm General Header)*:In order to represent
> recorded within the encompassingEncounter as participants…In
> a CCD the encompassingEncounter may be used when documenting
> a specific encounter and its participants.
>
> -**Care Team Members and Provider Names and Contact
> Information**)*:In most cases, multiple participants will be
> physician may see a patient in a clinical encounter, dictate
> a note, and legally authenticate the document. In this
> example, the consulting physician is participating as the
> 4 in that same section)*:componentOf/
> encompassingEncounter/ encounterParticipant:Care team member
> who participates in the encounter detailed in the document.
> Examples: PCP, consulting physician, attending
> the provision of care captured in the
> documentationOf/serviceEvent header element while care team
> members participating in the specific clinical encounter are
> the encounterParticipants within the
> componentOf/encompassingEncounter header element.
>
> explicitly//acknowledges////(and calls for)//the
> redundancy//://(//“//In most cases, multiple participants
> will be the same care team member//…”)//./
>
> In“Table 5-7 Sample CCD Participation Scenarios”*(again, in
> that same section)*there are two_ambulatory_examples(and one
> it’s a broad clinical summary and NOT about a specific
> encounter)and one is a consulting physicianproducinga CCD
> (because, as noted, there is an Encounters section that
> captures multiple encounters and associated team members)but
> in the specific-encounter CCDit statesvery
> as the responsible party for the clinical encounter and the
>
> I believe_everythi__n__g_above is consistent with what I presented in my
> articles– and, as best I can tell,_none_of it is consistent with what
> you have done in theambulatory sample. The decision to include
> encompassingEncounter/encounterParticipant) is based on whether there is
> a single primary encounter described in the document or not. It is NOT
> based on ambulatory vs. inpatient.
>
> sure, but it doesn’t matter**in this context..**. The**requirement here
> is**to create samples that are consisted with the documentation – not to
> published documentation**changed to match your sample. However, until
> you do, I think you need to follow the published guidance.***
> If you think your sample is consistent with the documentation, please
> explain how it aligns with the texts I noted above and/or others I may
> have missed. The CCD sample you created describes a single 30 minute
> C-CDA, and MU2 (S&I) documentation**does it say that leaving out
>
> /While I appreciate your views on the subject (and agree with many of
> them), i//t’s not helpful in this context to explain why redundancy is
> bad, why we should have a pointer mechanism,//what the history
> was,//what your feelings are//about where people have to look for
> information,//etc.//–/*/this is not a design forum for MU2 C-CDA
> documents –/**/we’re reviewing a/**/n official US
> government/**/sample/**/that/**/must be/**/properly/**/aligned with
> the/**/US government’s/**/published guidance/**/(the S&I Companion
> Guide, which in turn references the HL7 CDA and C-CDA specs)/*/.//So,
> let’s limit the discussion to that…/
>
>>
>
>>
> *From:*transport-t...@googlegroups.com<mailto:transport-t...@googlegroups.com>
>> [mailto:transport-t...@googlegroups.com] *On Behalf Of *Sairam
>
>> Sivaswami
>
>> *Sent:* Wednesday, April 02, 2014 06:17
>
>>
>
>>
> *Cc:*l...@nist.gov<mailto:l...@nist.gov>;LenG...@aol.com<mailto:LenG...@aol.com>
>> > For more options, visithttps://groups.google.com/d/optout.
>
>>
>
>> --
>
>> Andrew McCaffrey
>
>> andrew.m...@nist.gov<mailto:andrew.m...@nist.gov><javascript:>
>> ----
>
>> The words above do not necessarily reflect the opinions of my employers
>
>> or any organization I may be associated with. In fact, by the time you
>
>> read them, they may not even reflect my own opinions anymore.
>
>> ----
>
>> Any mention of commercial products within NIST web pages or email is
>
>> for
>
>> information only; it does not imply recommendation or endorsement by
>
>> NIST.
>
>>
>
>> --
>
>> You received this message because you are subscribed to the Google
>
>> Groups "Transport Testing Tool" group.
>
>> To unsubscribe from this group and stop receiving emails from it, send
>
>> an email
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>>.
>
>> For more options, visithttps://groups.google.com/d/optout.
>>
>
>> --
>
>> You received this message because you are subscribed to the Google
>
>> Groups "Transport Testing Tool" group.
>
>> To unsubscribe from this group and stop receiving emails from it, send
>
>> an email
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>>.
>
>> For more options, visithttps://groups.google.com/d/optout.
>
> --
>
> Andrew McCaffrey
>
> andrew.m...@nist.gov<mailto:andrew.m...@nist.gov>
> ----
>
> The words above do not necessarily reflect the opinions of my employers
> or any organization I may be associated with. In fact, by the time you
> read them, they may not even reflect my own opinions anymore.
>
> ----
>
> Any mention of commercial products within NIST web pages or email is for
> information only; it does not imply recommendation or endorsement by NIST.
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Transport Testing Tool" group.
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email
>
> For more options, visithttps://groups.google.com/d/optout.
Brian Weiss (CDA PRO)
Andrew,
I think we are definitely converging!
I think we are in agreement that the determining factor on whether componentOf/encompassingEncounter is in or not is the nature of the encounter(s) described in the document. If there is a single encounter, it clearly belongs. If there are multiple encounters over a period of time and none is the single, specific focus of the document, it should NOT be there (all the encounters should just be in the Body). There is some gray area here in the case where there are multiple encounters but one is "primary" in terms of "when the serviceEvent occurred" - but let's set that aside for now.
Now let's look at your sample ambulatory CCD:
1) The Encounters section in the Body lists only one encounter that happened on a single day
2) The "service event" of the document is defined as a 30 minute visit to the PCP on that day
So, although a CCD template is being used which is intended broadly for "longitudinal clinical summaries" this is very much a "visit summary" with only one encounter in it.
If you change the sample overall to be a "longitudinal clinical summary" covering an extended period with multiple encounters (listed in the Body!) - then I agree with you that you should not include componentOf/encompassingEncounter.
But that's not the case here - so assuming the rest of the sample is unchanged, componentOf/encompassingEncounter needs to be added in. The fact that it's an "ambulatory" summary is not, in and of itself, the issue…
I think what I wrote above is consistent with what you now wrote below? Just my conclusion re. this specific document is different because of the nature of the sample…
> *From:*transport-t...@googlegroups.com<mailto:transport-testin
>
>> [mailto:transport-t...@googlegroups.com] *On Behalf Of
>> *Sairam
>
>> Sivaswami
>
>> *Sent:* Wednesday, April 02, 2014 06:17
>
>>
> *To:*transport-t...@googlegroups.com<mailto:transport-testing-
>
>>
> *Cc:*l...@nist.gov<mailto:l...@nist.gov>;LenG...@aol.com<mailto:LenGall
> a...@aol.com>
>
>>
> <mailto:transport-testing...@googlegroups.com>>.
>
>> For more options, visithttps://groups.google.com/d/optout.
>
>>
>
>> --
>
>> You received this message because you are subscribed to the Google
>
>> Groups "Transport Testing Tool" group.
>
>> To unsubscribe from this group and stop receiving emails from it,
>> send
>
>> an email
> totransport-testin...@googlegroups.com<mailto:transport
> totransport-testing-tool+...@googlegroups.com>
To unsubscribe from this group and stop receiving emails from it, send an email to transport-testing...@googlegroups.com.
Lisa Nelson
I think it helps to think of the componentOf/encmpassingEncounter in the header as a way of establishing a context for "this encompassing encounter". When the document is produced to document a specific encompassing encounter, then that is the encounter which is documented in this special spot in the header. There may be other information in the document, which became known during a prior encounter and is being included in the documentation of "this encounter" because it is relevant, but all those other encounters are part of the past history that is available now for "this encounter". They appear documented in the body of the document, in the Encounter Section. They do not appear in the header, which is designed to allow us to understand the context of the document. That's why the header only allows for one encompassing encounter. It tells us which encounter is "this encounter". All the others are "those encounters", not "this one".
In the special case of a CCD that just covers a span of time, and may not have been produced in the context of "an encounter", then you have that special serviceEvent class of "PCPR" to handle establishing a context of care provision that happened over time. And, when the CCD is documenting a specific service or set of services for which this CCD was produced to document, then you use the more general serviceEvent class to indicate that the document is about "this service" and "this service" and "this server"...what was actually provided. Any other services which are included in the documentation because they provide historical information that is relevant for "this documentation" of "this service" will be found simply present in the body of the document. "those services" are historical information and are not recorded in the header.
The header allows the "new/current" acts to be "logged into being". After that, their content becomes "historical references" and is no longer recorded in the header. Remember, the header is just a quick reference for looking stuff up over time. The data in the header goes to making up the index. Service Events and Encounters need to be indexed into the longitudinal timeline at the point in time when they happened. That's why we only record serviceEvent information or Encounter information in the header when it is being directly recorded as the encounter or service "in focus" as the context of the document. That's how a proper longitudinal view is created.
Lisa
Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaR...@cox.net
From: transport-t...@googlegroups.com [mailto:transport-t...@googlegroups.com] On Behalf Of Andrew McCaffrey
Sent: Thursday, April 03, 2014 3:28 PM
To: transport-t...@googlegroups.com
Cc: l...@nist.gov; LenG...@aol.com
Subject: Re: Sample CCDA documents have missing information
Thanks for the discussion and I hope other people on the list can use this to further their own understanding (it's certainly prodding/helping me to think some of these issues through). We seem to have gotten onto a tangent. Perhaps I haven't been clear in my previous responses so I want to say a few things at the outset. NIST did not intentionally set out to “do what [we] feel is best and ignore what the documentation says”. We did not write samples to reflect what “should be”. You are correct; the samples (and indeed this mailing list) are not the appropriate venues for NIST to convey a contrary opinion on what the specifications should or shouldn't state and we did not wish to do so.
For longitudinal records, it not as clear. In CDA R2, componentOf has
0..1 cardinality. encompassingEncounter is 1..1. If the document contains several historical pieces of information (previous visits, previous surgeries, previous reported allergies) then multiple “encompassing” encounters would exist, but placing multiple pieces of data in this location is not possible.
Looking at Ambulatory in general, if a longitudinal record could be encompassed by a single encompassing encounter, then componentOf/encompassingEncounter would be an appropriate place to record that. If it can't be encompassed by a single encompassing encounter, then by CDA R2 those multiple pieces of information cannot be recorded here. In this particular MU2 sample scenario that we are discussing, it seemed ambiguous as to whether a single encompassing encounter was appropriate, so we recorded the information as shown in the sample XML.
Remember, that our sample is not intended to show all possible longitudinal Ambulatory possibilities. Certainly one could conceive of a Ambulatory record that would have only an unambiguous single encompassingEncounter. And indeed it would be appropriate for the information in that particular scenario to be recorded in componentOf/encompassingEncounter. But in this individual case, that cannot be determined unambiguously.
If MU were to point to a new Implementation Guide or newer specification (or a best practices paper) that stated something different, then we would of course update the samples to reflect this change. Until then, we have to do what the specifications state.
I hope this conveys what our thinking was in determining how to record information in these two samples.
Thanks,
Andrew
> Andrew,
>
> Lots of good points. Agree the redundancy is not good and a "pointer"
> some of the documentation as towhen encompassingEncounter and/or
> serviceEvent are optional and when they are required.BTW,you left off
> the Header
> - though right now this is guided to as beingfor
>
> be driving the creation ofthisNIST sampleright now. You have to very
> out encompassingEncounter".
>
> 1)*_CDA_**(4.2.3.5 encompassingEncounter)*:This optional
> during which the documented act(s) or ServiceEvent
> occurred…The encounterParticipant participant represents
> clinicians directly associated with the encounter (e.g. by
> initiating, terminating, or overseeing it).
>
> US Realm General Header)*:If the document is about a single
> 2.2 US Realm General Header)*:In order to represent
> recorded within the encompassingEncounter as participants…In
> a CCD the encompassingEncounter may be used when documenting
> a specific encounter and its participants.
>
> -**Care Team Members and Provider Names and Contact
> Information**)*:In most cases, multiple participants will be
> physician may see a patient in a clinical encounter, dictate
> a note, and legally authenticate the document. In this
> example, the consulting physician is participating as the
> 4 in that same section)*:componentOf/
> encompassingEncounter/ encounterParticipant:Care team member
> who participates in the encounter detailed in the document.
> Examples: PCP, consulting physician, attending
> the provision of care captured in the
> documentationOf/serviceEvent header element while care team
> members participating in the specific clinical encounter are
> the encounterParticipants within the
> componentOf/encompassingEncounter header element.
>
> explicitly//acknowledges////(and calls for)//the
> redundancy//://(//“//In most cases, multiple participants
> will be the same care team member//…”)//./
> In“Table 5-7 Sample CCD Participation Scenarios”*(again, in
> it’s a broad clinical summary and NOT about a specific
> (because, as noted, there is an Encounters section that
> in the specific-encounter CCDit statesvery
> clearly:/“//componentOf/encompassingEncounter//-//Captures
> as the responsible party for the clinical encounter and the
>
> I believe_everythi__n__g_above is consistent with what I presented in
> my articles– and, as best I can tell,_none_of it is consistent with
> what you have done in theambulatory sample. The decision to include
> encompassingEncounter/encounterParticipant) is based on whether there
> is a single primary encounter described in the document or not. It is
> NOT based on ambulatory vs. inpatient.
>
> If you think your sample is consistent with the documentation, please
> explain how it aligns with the texts I noted above and/or others I may
> have missed. The CCD sample you created describes a single 30 minute
> C-CDA, and MU2 (S&I) documentation**does it say that leaving out
>
> /While I appreciate your views on the subject (and agree with many of
> them), i//t’s not helpful in this context to explain why redundancy is
> information,//etc.//–/*/this is not a design forum for MU2 C-CDA
> government/**/sample/**/that/**/must be/**/properly/**/aligned with
> Guide, which in turn references the HL7 CDA and C-CDA specs)/*/.//So,
> let’s limit the discussion to that…/
>
>>
>
>>
> *From:*transport-t...@googlegroups.com<mailto:transport-testin
> g-t...@googlegroups.com>
>
>> *Sairam
>
>> Sivaswami
>
>> *Sent:* Wednesday, April 02, 2014 06:17
>
>>
> to...@googlegroups.com>
>
>>
> *Cc:*l...@nist.gov<mailto:l...@nist.gov>;LenG...@aol.com<mailto:LenGall
> a...@aol.com>
>
> totransport-testing-tool+...@googlegroups.com>
>> > For more options, visithttps://groups.google.com/d/optout.
>
>>
>
>> --
>
>> Andrew McCaffrey
>
>> andrew.m...@nist.gov<mailto:andrew.m...@nist.gov><javascript:>
>> ----
>
>> The words above do not necessarily reflect the opinions of my
>> employers
>
>> or any organization I may be associated with. In fact, by the time
>> you
>
>> read them, they may not even reflect my own opinions anymore.
>
>> ----
>
>> Any mention of commercial products within NIST web pages or email is
>
>> for
>
>> information only; it does not imply recommendation or endorsement by
>
>> NIST.
>
>>
>
>> --
>
>> You received this message because you are subscribed to the Google
>
>> Groups "Transport Testing Tool" group.
>
>> To unsubscribe from this group and stop receiving emails from it,
>> send
>
>> an email
> totransport-testing-tool+...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>>.
>
>> For more options, visithttps://groups.google.com/d/optout.
>>
>
>> --
>
>> You received this message because you are subscribed to the Google
>
>> Groups "Transport Testing Tool" group.
>
>> To unsubscribe from this group and stop receiving emails from it,
>> send
>
>> an email
> totransport-testing-tool+...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>>.
>
>> For more options, visithttps://groups.google.com/d/optout.
>
> --
>
> Andrew McCaffrey
>
> andrew.m...@nist.gov<mailto:andrew.m...@nist.gov>
> ----
>
> The words above do not necessarily reflect the opinions of my
> employers or any organization I may be associated with. In fact, by
> the time you read them, they may not even reflect my own opinions anymore.
>
> ----
>
> Any mention of commercial products within NIST web pages or email is
> for information only; it does not imply recommendation or endorsement by NIST.
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Transport Testing Tool" group.
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email
>
> For more options, visithttps://groups.google.com/d/optout.
Andrew McCaffrey
Hi Brian,
I think the argument can certainly be made (and you've made it very
well) that the single encounter listed in the Encounters section can be
regarded as an encompassing encounter. But can the entire document and
its data be definitively stated to have been encompassed from that
encounter? I don't see a strong enough statement in the scenario that
could be used to definitely state that one way or the other.
My inclination in an ambiguous case is to leave the sample as is. If it
were to be changed, I can envision someone coming along in six months
and asking it to be changed back, and I can't see any concrete reason
why they would be wrong.
In a way, it's probably better having this sample along side the
in-patient sample which uses componentOf/encompassingEcnounter. It
emphasizes to implementors that it would behoove them to look in
componentOf/encompassingEncounter , documentationOf/serviceEvent and (to
reference back to Lisa's helpful email) the entirety of the Encounters
section.
This has been a very interesting discussion. Thanks for jump-starting it.
-Andrew
On 04/03/2014 03:59 PM, Brian Weiss (CDA PRO) wrote:
> Andrew,
>
>
> I think we are in agreement that the determining factor on
> encounter, it clearly belongs. If there are multiple encounters over a
> should NOT be there (all theencountersshould just bein the Body). There
>
> Now let's look at your sample ambulatory CCD:
>
>
> 2) The "service event" of the document is defined as a 30
> So, although a CCD template is being used which is intended broadly for
> "longitudinal clinical summaries" this is very much a "visit summary"
> with only one encounter in it.
>
> If you change the sample overall to be a"longitudinal clinical
> summary"covering an extended period with multiple encounters (listed in
> the Body!) - then I agree with you that you should not include
> componentOf/encompassingEncounter.
>
> But that's not the case here - so assuming the rest of the sample is
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> >
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> > --
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>> > You received this message because you are subscribed to the Google
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>> > Groups "Transport Testing Tool" group.
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>> > To unsubscribe from this group and stop receiving emails from it,
>
>> > send
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> > an email
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> totransport-testin...@googlegroups.com<mailto:transport
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> totransport-testing-tool+...@googlegroups.com>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>> >
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> <
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>mailto:transport-testing...@googlegroups.com<
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> --
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> Andrew McCaffrey
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>
>
>> andrew.m...@nist.gov<
> <mailto:transport-testing...@googlegroups.com<mailto:transport-testing...@googlegroups.com>mailto:andrew.m...@nist.gov>
Lisa Nelson
Andrew,
I think the wording of your question may be what is making this difficult to understand. You asked, " But can the entire document and its data be definitively stated to have been encompassed from that encounter?" What makes more sent is to ask, "Does all the information in the document represent information that was available to/for the encounter participants at some point in time within the interval of time associated with the encompassing encounter?" And the answer is yes. Some of the information came into existence as a result of documenting the actions and observations which occurred during this encounter. Other information in the document was available as historical information for consideration as the patient during this encounter and was assessed as the plan of treatment was established then executed. If you think of how a clinician uses a SOAP approach, gathering subjective and objective information, then assessing that information, then creating the plan...you can see that the information which accumulated during past encounters actually becomes the "medical history information" which is used as the subjective and objective information for this current encounter. The information that was "new" under a prior encounter simply become "historical" within the context of a newer encounter. The historical information is an important part of the information that is available for the current encounter. Its presence in the patient's history may even figure significantly into the current assessment and plan.
I think there is low risk that this kind of temporal information processing would change in the future. I think it has taken a while for people to understand it, but now that more people do, the reality that time plays in the processing of information isn't likely to change. Over and over again (and hopefully forever), today's now becomes tomorrow's yesterday and today's tomorrow becomes now. A prior encounter's activities become this encounter's clinical history for the patient. Going forward this longitudinal reality will become clearer and clearer. This is one of the benefits of achieving greater continuity of care. Discontinuity is minimized or eliminated. What comes next encompasses what came before. I don't see any chance that someone will come along in six months and try to refute this reality.
Does that make sense? Does it address what you were questioning?
Lisa
Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaR...@cox.net
-----Original Message-----
From: transport-t...@googlegroups.com [mailto:transport-t...@googlegroups.com] On Behalf Of Andrew McCaffrey
Sent: Tuesday, April 08, 2014 2:11 PM
To: Brian Weiss (CDA PRO)
Cc: transport-t...@googlegroups.com; l...@nist.gov; LenG...@aol.com
Subject: Re: Sample CCDA documents have missing information
Hi Brian,
I think the argument can certainly be made (and you've made it very
well) that the single encounter listed in the Encounters section can be regarded as an encompassing encounter. But can the entire document and its data be definitively stated to have been encompassed from that encounter? I don't see a strong enough statement in the scenario that could be used to definitely state that one way or the other.
My inclination in an ambiguous case is to leave the sample as is. If it were to be changed, I can envision someone coming along in six months and asking it to be changed back, and I can't see any concrete reason why they would be wrong.
In a way, it's probably better having this sample along side the in-patient sample which uses componentOf/encompassingEcnounter. It emphasizes to implementors that it would behoove them to look in componentOf/encompassingEncounter , documentationOf/serviceEvent and (to reference back to Lisa's helpful email) the entirety of the Encounters section.
This has been a very interesting discussion. Thanks for jump-starting it.
-Andrew
On 04/03/2014 03:59 PM, Brian Weiss (CDA PRO) wrote:
> Andrew,
>
> I think we are definitely converging!
>
> I think we are in agreement that the determining factor on
> whethercomponentOf/encompassingEncounteris in or not is the nature of
> the encounter(s) described in the document. If there is a single
> encounter, it clearly belongs. If there are multiple encounters over a
> period of time and none is thesingle,specific focus of the document,
> it should NOT be there (all theencountersshould just bein the Body).
> There is some gray area here in the case where there are multiple
> encounters but one is "primary" in terms of "when the
> serviceEventoccurred"- but let's set that aside for now.
>
> Now let's look at your sample ambulatory CCD:
>
> 1) The Encounters section in theBodylists only one encounter
> that happened on a single day
>
> 2) The "service event" of the document is defined as a 30
> minute visit to the PCPon that day
>
> So, although a CCD template is being used which is intended broadly
> for "longitudinal clinical summaries" this is very much a "visit summary"
> with only one encounter in it.
>
> If you change the sample overall to be a"longitudinal clinical
> summary"covering an extended period with multiple encounters (listed
> in the Body!) - then I agree with you that you should not include
> componentOf/encompassingEncounter.
>
> But that's not the case here - so assuming the rest of the sample is
> unchanged,componentOf/encompassingEncounterneeds to be added in.The
> fact that it's an "ambulatory" summary is not, in and of itself, the
>
>>
>
>> >
>
>> <mailto:transport-testing...@googlegroups.com< a="">>>.
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
>
>> > For more options, visithttps://groups.google.com/d/optout.
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>> >
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>> > --
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
>
>> > You received this message because you are subscribed to the Google
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
>
>> > Groups "Transport Testing Tool" group.
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
>
>> > To unsubscribe from this group and stop receiving emails from it,
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>> > send
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
>> totransport-testin...@googlegroups.com<mailto:transpor
>> t
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>> totransport-testing-tool+...@googlegroups.com>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>> >
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>> <
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> a="">>>.
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
>
>> > For more options, visithttps://groups.google.com/d/optout.
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>> --
> <mailto:transport-testing...@googlegroups.com<mailto:tra
> nsport-testing-...@googlegroups.com>
>
>>
> <mailto:transport-testing...@googlegroups.com<mailto:tra
>
>>
>
>> ----
>
>>
>
>> The words above do not necessarily reflect the opinions of my
>
>> employers or any organization I may be associated with. In fact, by
>
>> the time you read them, they may not even reflect my own opinions anymore.
>
>>
>
>> ----
>
>>
>
>> Any mention of commercial products within NIST web pages or email is
>
>> for information only; it does not imply recommendation or
>> endorsement
> by NIST.
>
>>
>
>> --
>
>>
>
>> You received this message because you are subscribed to the Google
>
>> Groups "Transport Testing Tool" group.
>
>>
>
>> To unsubscribe from this group and stop receiving emails from it,
>> send
>
>> an email
>
>>
> totransport-testin...@googlegroups.com<mailto:transport
> totransport-testing-tool+...@googlegroups.com
> <mailto:transport-testing...@googlegroups.com>>.
>
>>
>
>> For more options, visithttps://groups.google.com/d/optout.
>
>>
>
>> --
>
>> You received this message because you are subscribed to the Google
>
>> Groups "Transport Testing Tool" group.
>
>> To unsubscribe from this group and stop receiving emails from it,
>> send
>
>> an email to transport-testing...@googlegroups.com
>
>> <mailto:transport-testing...@googlegroups.com
Brian Weiss (CDA PRO)
Are you referring to the files located here:
http://transport-testing.nist.gov/ttt/toolkitx/testkit/direct-messages/CCDA_Inpatient.xml
http://transport-testing.nist.gov/ttt/toolkitx/testkit/direct-messages/CCDA_Ambulatory.xml
I believe they both include componentOf/encompassingEncounter...
It's not an absolute requirement that MU2 documents have this in their header (depends on whether there is an "encompassing encounter" or not - see the snippet below from the S&I Companion Guide that shows three scenarios, two include componentOf/encompassingEncounter participants but the first does not as they are detailed in the Encounters section of the body).
But unless we are not looking at the same sample, I do see componentOf/encompassingEncounter in both...
Brian Weiss
Brian
Buy your high quality real or fake passport,(fani...@gmail.com) Counterfeit Bills,Real and Fake Driver’s licenses, ID cards, visas, stamps, diploma, certificates, degrees, citizenship and other products for a number of countries like: USA, Australia, Belgium, Brazil, Canada, Italy, Finland, France, Germany, Israel, Russia,Mexico, Finland,Netherlands ,South Africa,Spain,United Kingdom.Japan when producing; magnetic encoded strips and/or scan able bar-code. UV-spectrum analysis test standards,magnetic strip, Watch video here for more details........... http://vimeo.com/82973635 Contact us............... fani...@gmail.com Email.......................... fani...@yahoo.com SKYPE US for quick chat …………….. fandena.fandena SKYPE US for quick chat …………….. fandena.fandena SKYPE US for quick chat …………….. fandena.fandena Contact e-mails: fani...@gmail.com Technical support: fani...@gmail.com