Difference between revisions of "XDS-SD OID"

From IHE Wiki
Jump to navigation Jump to search
(New page: Back to: XDS-SD_Harmonization __TOC__ <!-- <noinclude> {{:PCC TF-1/Header|Scanned Documents (XDS-SD)}} </noinclude> --> ==Scanned Documents Content Integration Profile== A variety of ...)
 
 
(21 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
Back to: [[XDS-SD_Harmonization]]
 
Back to: [[XDS-SD_Harmonization]]
−
__TOC__
 
−
<!-- <noinclude>
 
−
{{:PCC TF-1/Header|Scanned Documents (XDS-SD)}}
 
−
</noinclude>
 
−
-->
 
  
−
==Scanned Documents Content Integration Profile==
+
{{CDA Document|Scanned Document|formatCode=urn:ihe:iti:xds-sd:pdf:2008 or urn:ihe:iti:xds-sd:text:2008|XDS-SD OID|Trial|
−
A variety of legacy paper, film, electronic and scanner outputted formats are used to store and exchange clinical documents. These formats are not designed for healthcare documentation, and furthermore, do not have a uniform mechanism to store healthcare metadata associated with the documents, including patient identifiers, demographics, encounter, order or service information.  The association of structured, healthcare metadata with this kind of document is important to maintain the integrity of the patient health record as managed by the source system. It is necessary to provide a mechanism that allows such source metadata to be stored with the document.
 
−
This profile defines how to couple such information, represented within a structured HL7 CDA R2 header, with a PDF or plaintext formatted document containing clinical information. Furthermore, this profile defines elements of the CDA R2 header necessary to minimally annotate these documents. Such header elements include information regarding patient identity, patient demographics, scanner operator identity, scanning technology, scan time as well as best available authoring information.  Portions of CDA R2 header, along with supplemental document registration information, are then used to populate XDS Document Entry metadata.
 
−
 
 
−
The content of this profile is intended for use in XDS, XDR and XDM. Content is created by a Content Creator and is to be consumed by a Content Consumer.  The Content Creator can be embodied by a Document Source Actor or a Portable Media Creator, and the Content Consumer by a Document Consumer, a Document Recipient or a Portable Media Importer. Obligations imposed on the Content Creator and the Content Consumer by this profile are understood to be fulfilled by the software that creates the final document for submission and/or consumes profile conformant documents rather than any particular scanning technology.
 
−
 
 
−
===Dependencies===
 
−
<pre>Add the following row(s) to the list of dependencies</pre>
 
−
{|style='background-color:#7f7f7f;' align='center' border='1' cellspacing='0'
 
−
!Integration Profile
 
−
!Dependency
 
−
!Dependency Type
 
−
!Purpose
 
−
|- style='background-color:#ffffff;' align='center'
 
−
|XDS-SD
 
−
|CDA R2
 
−
|XDS-SD is a conformant HL7 CDA R2 document
 
−
|XDS-Lab constrains CDA R2 for the purposes of communicating scanned content
 
−
|- style='background-color:#ffffff;' align='center'
 
−
|XDS-SD s
 
−
|PDF RFC 3778, The application/pdf Media Type (informative)
 
−
|todo
 
−
|todo
 
−
|- style='background-color:#ffffff;' align='center'
 
−
|XDS-SD
 
−
|PDF/A ISO 19005-1. Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF (PDF/A)
 
−
|todo
 
−
|todo
 
−
|-
 
−
|}
 
−
 
 
−
{{Content Profile Actors and Transactions|PHLab}}
 
−
 
 
−
{{PCC Content Profile Options|PHLab|Creator=}}
 
−
 
 
−
{{:PCC TF-1/Coded Terminologies}}
 
−
 
 
−
{{XD* Binding|Scanned Documents|XDS-SD|
 
−
Bindings={{Binding|Scanned Documents}}
 
−
}}
 
−
 
 
−
===XDS Scanned Document Content Module===
 
−
====Content Use Cases====
 
−
'''Text Chart Notes'''
 
−
Examples of this content include handwritten, typed or word processed clinical documents and/or chart notes.
 
−
These documents are typically multi-page, narrative text.  They include preprinted forms with handwritten responses, printed documents, and typed and/or word processed documents, and documents saved in various word processing formats. Appropriate formats are PDF, derived from the word processing format, or plaintext, if the text structure is all that needs to be conveyed. PDF is desirable because it most faithfully renders word processed document content.
 
−
'''Graphs, Charts and/or Line Drawings'''
 
−
Examples of this content include Growth Charts, Fetal Monitoring Graphs.
 
−
Line drawings such as those described above are best rendered using PDF versus an image based compression, such as JPEG.  However, when computer generated PDFs include lines, PDF vector encoding should be used.
 
−
'''Object Character Recognition (OCR) Scanned Documents'''
 
−
Clinical documents can contain text and annotations that cannot be fully processed by optical character recognition (OCR).  We call attention to the fact that the OCR text content may only partially represent the document content. These are best supported by converting to PDF format, which can mix the use of OCR’d text, compressed scanned text, and scanned image areas.
 
−
'''Electronic Documents'''
 
−
Existing clinical documents that are electronically transmitted or software created (e.g. PDF, or plaintext) can be considered as actually scanned, previously scanned or virtually scanned before they are shared.  In this context, “actually scanned” refers to electronic documents, newly created via some scanning technology from legacy paper or film for the purposes of sharing. “Previously scanned” refers to electronic documents that were previously produced via some scanning technology from legacy paper or film, but have existed in their own right for a period of time. “Virtually Scanned” electronic documents are existing electronic documents not derived from legacy paper or film that either are PDF/A or plaintext format or have been converted to one of these formats for the purposes of sharing. This content is covered by this profile.
 
−
 
 
−
====Content Creator Use Cases====
 
−
Content is created by a Content Creator. Impact on application function and workflow is implementation specific and out of scope of this content profile, though we note that they will be compliant with this content profile if they can produce CDA wrapped PDF, CDA wrapped plaintext or both. The following example use case is included to aid in the scoping of this content profile.
 
−
 
 
−
Legacy Clinic is a small two-physician clinic.  They presently store their patient's medical records on paper.  The Clinic is trying to figure out what to do with its paper and word processing documents as it converts over to an electronic system.  They plan would like to be able to view the files over their local intranet.
 
−
Presently, most records are handwritten on preprinted paper forms that are inserted into specific sections of the patient's chart.  More detailed encounter reports are dictated and sent to a transcription company that returns them in a word processing format. The medical records clerk at Legacy Clinic receives these files via e-mail, decrypts them, prints them out, and adds them to the patient's chart in the correct section.
 
−
Over the years, Legacy Clinic has used a number of different transcription companies, and the documents are stored in a variety of word processing formats.  Several years ago, they began to require that returned documents be in RTF format in an attempt to reduce frustrations induced by dealing with discrepant word processing formats.  Only in some cases was patient and encounter metadata stored within the word processing document in a regular format, depending upon the transcription company used at the time.
 
−
A third party presently handles labs for the clinic.  These are usually returned to the Clinic as printed documents.  The clerk inserts these into the labs section in the patient's chart.
 
−
In the case of Legacy Clinic, the link between the word processing documents and the patient has been maintained for many of its documents, since the existing manual process maintains that association, and some of the files also contain the encounter metadata.  However, the link to the specific encounter will need to be reestablished by interpreting the document content, which will require a great deal of manual effort for some of their documents which do not have it, and will still require custom handling depending upon the format used to store this metadata.
 
−
Legacy Clinic uses a transcription provider that can generate PDF documents, wrapped in a CDA Release 2.0 header.  These are sent to Legacy Clinic via e-mail.  While the same manual process is used, these documents are now in a format that is ready to be used by their new EHR system.
 
−
 
 
−
====Content Consumer Use Cases====
 
−
Content is consumed by a Content Consumer. Impact on application function and workflow is implementation specific and out of scope of this content profile. However, we note that adoption of this profile will necessitate the Content Consumer, upon document receipt, support the processing of both CDA wrapped PDF and CDA wrapped plaintext.
 
−
 
 
−
====Content Creation Process====
 
−
This profile assumes the following sequence of events in creation of an XDS-SD document.
 
−
#A legacy paper document is scanned and a PDF/A is rendered. Alternatively, an electronic document is converted, if necessary, to PDF/A or plaintext format (see ?7.1.3 and ?7.1.4).
 
−
#Software, conformant to this profile and most likely with the aid of user input (ex. to provide document title, confidentiality code, original author), renders the CDA R2 header pertaining to the PDF or plaintext produced. The document is wrapped and the XDS-SD document is completed (see ?7.1.8).
 
−
#XDS metadata is produced from data contained in the CDA header and supplemental information (see ?7.1.5).
 
−
#The completed XDS-SD document and corresponding metadata is sent via the Provide an Register Document Set Transaction [ITI-15] of XDS/XDR, or the Distribute Document Set on Media Transaction [ITI-32] of XDM.
 
−
 
 
−
 
 
−
===Grouping with Other Actors===
 
−
====Cross Enterprise Document Sharing, Media Interchange and Reliable Messaging====
 
−
The Content Creator and Content Consumer Actors shall be grouped with appropriate actors from the XDS, XDM or XDR integration profiles to support sharing of PHLab documents.
 
−
 
 
−
====Document Digital Signature (DSG)====
 
−
Content Creator actors should digitally sign all documents using the Digital Signature (DSG) Content Profile.
 
−
 
 
−
Content Consumer actors should verify the Digital Signature of the submission set before use of the information it contains.
 
−
 
 
−
<!--
 
−
<noinclude>
 
−
{{:PCC TF-1/Trailer}}
 
−
 
 
−
=Volume II=
 
−
{{:PCC TF-2/Header|Public Health Laboratory Report (PHLAB)}}
 
−
</noinclude>
 
−
-->
 
−
 
 
−
{{CDA Document|Scanned Document|formatCode=urn:ihe:iti:xds-sd:2008|tbd|Trial|
 
 
This section outlines the content of the HL7 CDA R2 wrapper for the document. We note here that requirements specified below are to ensure the presence of a minimum amount of wrapper data in order to enhance description and facilitate sharing of the document. Implementers of this profile can and should make use of additional annotation within the CDA header to provide richer context. The examples in the following sections contain the minimal amount of wrapper data, as specified, and in many cases do make use of additional CDA header elements for enriched context.  
 
This section outlines the content of the HL7 CDA R2 wrapper for the document. We note here that requirements specified below are to ensure the presence of a minimum amount of wrapper data in order to enhance description and facilitate sharing of the document. Implementers of this profile can and should make use of additional annotation within the CDA header to provide richer context. The examples in the following sections contain the minimal amount of wrapper data, as specified, and in many cases do make use of additional CDA header elements for enriched context.  
 +
<br>
 +
<br>
 
'''Assumptions and Definitions'''
 
'''Assumptions and Definitions'''
 
We assume that the scanning facility and equipment within it are assigned an OID and that the scanning facility assembles the wrapped scanned content. More information regarding the construction of OIDS can be found in the ITI Technical Framework, Volume 2, Appendix B.
 
We assume that the scanning facility and equipment within it are assigned an OID and that the scanning facility assembles the wrapped scanned content. More information regarding the construction of OIDS can be found in the ITI Technical Framework, Volume 2, Appendix B.
Line 110: Line 14:
  
 
|Standards={{Std|CDAR2}}
 
|Standards={{Std|CDAR2}}
−
{{Std|CRS}}
+
{{Std|PDF RFC 3778, The application/pdf Media Type (informative)}}
−
<!-- {{Std|CCD}} -->
+
{{Std|PDF/A ISO 19005-1b. Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF (PDF/A) }}
−
|Parent=1.3.6.1.4.1.19376.1.5.3.1.1.2|ParentName=Medical Summary <--! parent is CDA, not medical summary -->
+
{{Std|IETF (Internet Engineering Task Force) RFC 3066}}
−
|Index={{T|Data Elements|HL7 Care Record Summary|CDA Release 2.0|
+
 
 +
|Index={{T|Data Elements|CDA Release 2.0|
 
Rows=
 
Rows=
−
{{R|Original Author|?|author}}
+
{{R|Original Author|author}}
−
{{R|Scanner|?|author}}
+
{{R|Scanner|author}}
−
{{R|Scanner Operator|?|dataEnterer}}
+
{{R|Scanner Operator|dataEnterer}}
 
}}
 
}}
−
|HL7V3|Original Author|R2?|tbd|
+
|HL7V3|Original Author|R2|Original Author OID|
−
|HL7V3|Scanner|R?|tbd|
+
|HL7V3|Scanner|R|Scanner OID|
−
|HL7V3|Scanner Operator|R?|tbd|
+
|HL7V3|Scanner Operator|R|Scanner Operator OID|
 
}}
 
}}
  
 
===ClinicalDocument Header rendering===  
 
===ClinicalDocument Header rendering===  
−
todo
 
 
====ClinicalDocument Header constraints====
 
====ClinicalDocument Header constraints====
−
=====<template id="1.3.6.1.4.1.19376.1.3.3"/>=====
+
=====<typeId/>=====
−
ClinicalDocument/templateId shall be present and shall have root value of "tbd" to signify that this ClinicalDocument conforms to the XDS-Lab content profile specification.
+
ClinicalDocument/typeId shall be present and shall be as stated in the HL7 CDA R2 Standard.
 +
* Example: <typeId root="2.16.840.1.113883.1.3" extension="POCD_H000040"
 +
=====<template id="XDS-SD OID"/>=====
 +
ClinicalDocument/templateId shall be present and shall have root value of "XDS-SD OID" to signify that this ClinicalDocument conforms to the XDS-SD content profile specification.
 +
=====<id/>=====
 +
The ClinicalDocument/id element shall be present. The root attribute shall contain the oid for the document, in which case the extension attribute shall be empty, or an oid that scopes the set of possible unique values for the extention attribute, in which case the extension shall be populated with a globally unique identifier within the scope of the root oid.  
 
=====<code/>=====
 
=====<code/>=====
 +
The ClinicalDocument/code will in most cases be provided by the operator. Values for this code are dictated by the CDA R2 documentation, but are permissible to extend to fit the particular use case. Attributes code@code and code@codeSystem shall be present.
 +
=====<title/>=====
 +
The ClinicalDocument/title shall be present if known.
 +
=====<effectiveTime/>=====
 +
The ClinicalDocument/effectiveTime shall denote the time at which the original content was scanned. At a minimum, the time shall be precise to the day and shall include the time zone offset from GMT.
 +
=====<confidentalityCody/>=====
 +
The ClinicalDocument/confidentialityCode shall be assigned by the operator in accordance with the scanning facility policy. The notion or level of confidentiality in the header may not be the same as that in the Affinity Domain, but in certain cases could be used to derive a confidentiality value among those specified by the Affinity Domain. Attributes confidentialityCode@code and confidentialityCode@codeSystem shall be present.
 +
=====<languageCode/>=====
 +
The ClinicalDocument/languageCode, in accordance with the HL7 CDA R2 documentation, shall denote the language used in the character data of the wrapper CDA header. If the scanned content, when rendered, is in a language different than that of the header, the language context of the CDA will be overwritten at the body level (see ‎[[XDS-SD_OID#ClinicalDocument Body]] ClinicalDocument/component/nonXMLBody for an example). Attribute code@code shall be present. Attribute code@codeSystem shall be IETF (Internet Engineering Task Force) RFC 3066 in accordance with the HL7 CDA R2 documentation.
 
=====<recordTarget/>=====
 
=====<recordTarget/>=====
 +
The ClinicalDocument/recordTarget contains identifying information about the patient concerned in the original content.  In many cases this will have to be supplied by the operator. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.
 +
* The ClinicalDocument/recordTarget/patientRole/id element shall include both the root and the extension attributes. Refer back to ‎[[PCC_TF-2/Bindings]] for more details.
 +
* At least one ClinicalDocument/recordTarget/patientRole/addr element shall include at least the country subelement. The addr element has an unbounded upper limit on occurrences. It can, and should, be replicated to include additional addresses for a patient, each minimally specified by the country subelement.
 +
* At least one ClinicalDocument/recordTarget/patientRole/patient/name element shall be at least one given subelement and one family subelement.
 +
* The ClinicalDocument/recordTarget/patientRole/patient/administrativeGenderCode element shall be present.
 +
* The ClinicalDocument/recordTarget/patientRole/patient/birthTime element shall be present with precision to the year.
 
=====<custodian/>=====
 
=====<custodian/>=====
 +
The ClinicalDocument/custodian shall be present. Its context is left up to the scanning facility to refine in accordance with local policies and to reflect the entity responsible for the scanned content. In most cases this will be the scanning facility. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.
 +
* The ClinicalDocument/assignedCustodian/representedOrganization/name shall be present.
 +
* At least one ClinicalDocument/assignedCustodian/representedOrganization/addr element shall include at least the country subelement.
 
=====<legalAuthenticator/>=====
 
=====<legalAuthenticator/>=====
 +
The ClinicalDocument/legalAuthenticator may be present and its context is left up to the scanning facility to refine in accordance with local policies. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.
 +
* The ClinicalDocument/legalAuthenticator/assignedEntity/id element if known shall include both the root and the extension attributes. Refer back to ‎[[PCC_TF-2/Bindings]] for more details.
 
=====<documentationOf/>=====
 
=====<documentationOf/>=====
−
 
+
This ClinicalDocument/documentationOf element is used to encode the date/time range of the original content. If the original content is representative of a single point in time then the endpoints of the date/time range shall be the same. Information regarding this date/time range shall be included, if it is known. In many cases this will have to be supplied by the operator. This profile does not restrict the documentationOf element beyond statements made in the HL7 CDA R2 documentation.
−
=====ClinicalDocument Header Content Modules====
+
====ClinicalDocument Header Content Modules====
−
The table [[#Specification|above]] lists the additional requirements (conformance statements) for this laboratory report which are in the form of header content modules.
+
The table [[#Specification|above]] lists the additional requirements (conformance statements) for this scanned document which are in the form of header content modules.
 
====ClinicalDocument Header Example====
 
====ClinicalDocument Header Example====
 
<pre>
 
<pre>
 +
<ClinicalDocument xmlns="urn:hl7-org:v3"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" classCode="DOCCLIN" moodCode="EVN" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">
 +
  <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>
 +
  <templateId root="XDS-SD OID"/>
 +
  <id root=“1.3.6.4.1.4.1.2835.2.7777”/>
 +
  <code code=“34133-9”  codeSystem=“2.16.840.1.113883.6.1”
 +
codeSystemName=“LOINC” displayName=“SUMMARIZATION OF EPISODE NOTE”/>
 +
  <title>Good Health Clinic Care Record Summary</title>
 +
  <effectiveTime value=“20050329224411+0500”/>
 +
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
 +
  <languageCode code=“en-US”/>
 +
  <recordTarget>
 +
    <patientRole>
 +
      <id extension="12345" root="2.16.840.1.113883.3.933"/>
 +
      <addr>
 +
        <streetAddressLine>17 Daws Rd.</streetAddressLine>
 +
        <city>Blue Bell</city>
 +
        <state>MA</state>
 +
        <postalCode>02368</postalCode>
 +
        <country>USA</country>
 +
      </addr>
 +
      <patient>
 +
        <name>
 +
          <prefix>Mrs.</prefix>
 +
          <given>Ellen</given>
 +
          <family>Ross</family>
 +
        </name>
 +
        <administrativeGenderCode code="F"
 +
codeSystem="2.16.840.1.113883.5.1"/>
 +
        <birthTime value="19600127"/>
 +
      </patient>
 +
  </patientRole>
 +
  </recordTarget>
 +
  <author>
 +
    <templateId root="Original Author OID"/>
 +
    <time value=“19990522”/>
 +
    <assignedAuthor>
 +
      <id extension=“11111111” root=“1.3.5.35.1.4436.7”/>
 +
      <assignedPerson>
 +
        <name>
 +
          <prefix>Dr.</prefix>
 +
          <given>Bernard</given>
 +
          <family>Wiseman</family>
 +
          <suffix>Sr.</suffix>
 +
        </name>
 +
      </assignedPerson>
 +
    <representedOrganization>
 +
  <id extension=“aaaaabbbbb” root=“1.3.5.35.1.4436.7”/>
 +
  <name>Dr. Wiseman’s Clinic</name>
 +
      </representedOrganization>
 +
    </assignedAuthor>
 +
  </author>
 +
  <author>
 +
    <templateId root="Scanner OID"/>
 +
    <time value=“20050329224411+0500”/>
 +
    <assignedAuthor>
 +
      <id root=“1.3.6.4.1.4.1.2835.2.1234”/>
 +
      <assignedAuthoringDevice>
 +
<code code=“CAPTURE” displayName=“Image Capture” codeSystem=“  1.2.840.10008.2.16.4” />
 +
<manufacturerModelName>SOME SCANNER NAME AND MODEL  </manufacturerModelName>
 +
        <softwareName>SCAN SOFTWARE NAME v0.0</softwareName>
 +
    </assignedAuthoringDevice>
 +
    <representedOrganization>
 +
  <id root=“1.3.6.4.1.4.1.2835.2”/>
 +
  <name>SOME Scanning Facility</name>
 +
        <addr>
 +
          <streetAddressLine>21 North Ave</streetAddressLine>
 +
          <city>Burlington</city>
 +
          <state>MA</state>
 +
          <postalCode>01803</postalCode>
 +
          <country>USA</country>
 +
        </addr>
 +
      </representedOrganization>
 +
  </assignedAuthor>
 +
</author>
 +
  <dataEnterer>
 +
    <templateId root="Scanner Operator OID"/>
 +
    <time value=“20050329224411+0500”/>
 +
    <assignedEntity>
 +
      <id extension=“22222222” root=“1.3.6.4.1.4.1.2835.2”/>
 +
      <assignedPerson>
 +
        <name>
 +
          <prefix>Mrs.</prefix>
 +
          <given>Bernice</given>
 +
          <family>Smith</family>
 +
        </name>
 +
      </assignedPerson>
 +
    </assignedEntity>
 +
  </dataEnterer>
 +
  <custodian>
 +
    <assignedCustodian>
 +
      <representedCustodianOrganization>
 +
  <id root=“1.3.6.4.1.4.1.2835.2”/>
 +
  <name>SOME Scanning Facility</name>
 +
        <addr>
 +
          <streetAddressLine>21 North Ave</streetAddressLine>
 +
          <city>Burlington</city>
 +
          <state>MA</state>
 +
          <postalCode>01803</postalCode>
 +
          <country>USA</country>
 +
        </addr>
 +
      </representedCustodianOrganization>
 +
    </assignedCustodian>
 +
  </custodian>
 +
  <legalAuthenticator>
 +
    <time value=“19990522”/>
 +
    <signatureCode code=“S”/>
 +
    <assignedEntity>
 +
      <id extension=“11111111” root=“1.3.5.35.1.4436.7”/>
 +
      <assignedPerson>
 +
        <name>
 +
          <prefix>Dr.</prefix>
 +
          <given>Bernard</given>
 +
          <family>Wiseman</family>
 +
          <suffix>Sr.</suffix>
 +
        </name>
 +
      </assignedPerson>
 +
    </assignedEntity>
 +
  </legalAuthenticator>
 +
  <documentationOf>
 +
    <serviceEvent >
 +
      <effectiveTime>
 +
        <low value=“19800127”/>
 +
        <high value=“19990522”/>
 +
      </effectiveTime>
 +
    </serviceEvent>
 +
  </documentationOf>
 +
  <component>
 +
    <nonXMLBody>
 +
 +
    ... scanned content here ...
 +
    </nonXMLBody>
 +
  </component>
 +
</ClinicalDocument>
 +
 
</pre>
 
</pre>
  
 
===ClinicalDocument Body===  
 
===ClinicalDocument Body===  
−
The scanned document shall have a nonXMLBody.
+
This ClinicalDocument/component/nonXMLBody element shall be present and used to wrap the scanned content. The nonXMLBody element is guaranteed to be unique; thus the x-path to recover the scanned content is essentially fixed. All subelements of the nonXMLBody retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.
 +
* If the human-readable language of the scanned content is different than that of the wrapper (specified in ClinicalDocument/languageCode), then ClinicalDocument/component/nonXMLBody/languageCode shall be present. Attribute code@code shall be present. Attribute code@codeSystem shall  be IETF (Internet Engineering Task Force) RFC 3066 in accordance with the HL7 CDA R2 documentation.
 +
* The ClinicalDocument/component/nonXMLBody/text element shall be present and encoded using xs:base64Binary encoding. Its #CDATA will contain the scanned content.
 +
** ClinicalDocument/component/nonXMLBody/text@mediaType shall be “application/pdf” for PDF, or “text/plain” for plaintext.
 +
** ClinicalDocument/component/nonXMLBody/text@representation shall be present. The @representation for both PDF and plaintext scanned content will be “B64”, because this profile requires the base-64 encoding of both formats.
 +
 
 +
 
 
====ClinicalDocument Body Example====
 
====ClinicalDocument Body Example====
 +
Example (PDF scanned content is in the same language as the wrapper):
 +
<pre>
 +
<ClinicalDocument>
 +
... CDA header content here ...
 +
  <component>
 +
    <nonXMLBody>
 +
      <text mediaType=“application/pdf” representation=“B64”>
 +
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0
 +
ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB
 +
Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx
 +
a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO
 +
BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu
 +
K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0
 +
...
 +
SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48
 +
RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx
 +
MgolJUVPRgo=
 +
    </text>
 +
    </nonXMLBody>
 +
  </component>
 +
</ClinicalDocument>
 +
</pre>
 +
 +
 +
Example (PDF scanned content is in a different language as the wrapper):
 
<pre>
 
<pre>
 +
<ClinicalDocument>
 +
... CDA header content here ...
 +
  <component>
 +
    <nonXMLBody>
 +
<languageCode code=“zh-CN”/>
 +
      <text mediaType=“application/pdf” representation=“B64”>
 +
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0
 +
ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB
 +
Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx
 +
a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO
 +
BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu
 +
K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0
 +
...
 +
SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48
 +
RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx
 +
MgolJUVPRgo=
 +
      </text>
 +
    </nonXMLBody>
 +
  </component>
 +
</ClinicalDocument>
 
</pre>
 
</pre>

Latest revision as of 14:12, 22 May 2008

Back to: XDS-SD_Harmonization

Development Only

The PCC Wiki Content is used only for development of IHE PCC Content. The Normative content of the PCC Technical Framework and the current supplements can be found at http://www.ihe.net/Technical_Framework/index.cfm#PCC

Trial.gif Scanned Document Specification XDS-SD OID

This section outlines the content of the HL7 CDA R2 wrapper for the document. We note here that requirements specified below are to ensure the presence of a minimum amount of wrapper data in order to enhance description and facilitate sharing of the document. Implementers of this profile can and should make use of additional annotation within the CDA header to provide richer context. The examples in the following sections contain the minimal amount of wrapper data, as specified, and in many cases do make use of additional CDA header elements for enriched context.

Assumptions and Definitions We assume that the scanning facility and equipment within it are assigned an OID and that the scanning facility assembles the wrapped scanned content. More information regarding the construction of OIDS can be found in the ITI Technical Framework, Volume 2, Appendix B. We define the following nomenclature for entity roles concerned in forming the wrapper content.

  • Original content – Legacy paper or electronic document intended for wrapping.
  • Scanned content – Scanned or appropriately converted/encoded electronic version of the original content.
  • Original author – Author of the original content.
  • (Scanner) Operator – Person assembling the scanned content.


Format Code

The XDSDocumentEntry format code for this content is urn:ihe:iti:xds-sd:pdf:2008 or urn:ihe:iti:xds-sd:text:2008


Standards
CDAR2 HL7 CDA Release 2.0
PDF RFC 3778, The application/pdf Media Type (informative) [ ]
PDF/A ISO 19005-1b. Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF (PDF/A) [ ]
IETF (Internet Engineering Task Force) RFC 3066 [ ]
Data Element Index
Data Elements CDA Release 2.0
Original Author author
Scanner author
Scanner Operator dataEnterer
Specification
Data Element Name Opt Template ID
Original Author R2 Original Author OID
Scanner R Scanner OID
Scanner Operator R Scanner Operator OID


Conformance

CDA Release 2.0 documents that conform to the requirements of this content module shall indicate their conformance by the inclusion of the appropriate <templateId> elements in the header of the document. This is shown in the sample document below.

Sample Scanned Document Document 
<ClinicalDocument xmlns='urn:hl7-org:v3'>
  <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>
  <templateId root='XDS-SD OID'/>
  <id root=' ' extension=' '/>
  <code code=' ' displayName=' '
    codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
  <title>Scanned Document</title>
  <effectiveTime value='20240423012005'/>
  <confidentialityCode code='N' displayName='Normal' 
    codeSystem='2.16.840.1.113883.5.25' codeSystemName='Confidentiality' />
  <languageCode code='en-US'/>     
     :
  <component><structuredBody>
       
  </structuredBody></component>
</ClinicalDocument>
Schematron
<pattern name='Template_XDS-SD OID'>
 <rule context='*[cda:templateId/@root="XDS-SD OID"]'>
   <!-- Verify that the template id is used on the appropriate type of object -->
   <assert test='../cda:ClinicalDocument'>
     Error: The Scanned Document can only be used on Clinical Documents.
   </assert> 
   <!-- Verify the document type code -->
   <assert test='cda:code[@code = "{{{LOINC}}}"]'>
     Error: The document type code of a Scanned Document must be {{{LOINC}}}
   </assert>
   <assert test='cda:code[@codeSystem = "2.16.840.1.113883.6.1"]'>
     Error: The document type code must come from the LOINC code 
     system (2.16.840.1.113883.6.1).
   </assert> 
   <assert test='.//cda:templateId[@root = "Original Author OID"]'> 
     <!-- Alert on any missing required if known elements -->
     Warning: The  Scanned Document Document should contain a(n) Original Author HL7V3.
     See http://wiki.ihe.net/index.php?title=XDS-SD OID
   </assert> 
   <assert test='.//cda:templateId[@root = "Scanner OID"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Scanned Document Document must contain a(n) Scanner HL7V3.
     See http://wiki.ihe.net/index.php?title=XDS-SD OID
   </assert> 
   <assert test='.//cda:templateId[@root = "Scanner Operator OID"]'> 
     <!-- Verify that all required data elements are present -->
     Error: The Scanned Document Document must contain a(n) Scanner Operator HL7V3.
     See http://wiki.ihe.net/index.php?title=XDS-SD OID
   </assert> 
 </rule>
</pattern>

ClinicalDocument Header rendering

ClinicalDocument Header constraints

<typeId/>

ClinicalDocument/typeId shall be present and shall be as stated in the HL7 CDA R2 Standard.

  • Example: <typeId root="2.16.840.1.113883.1.3" extension="POCD_H000040"
<template id="XDS-SD OID"/>

ClinicalDocument/templateId shall be present and shall have root value of "XDS-SD OID" to signify that this ClinicalDocument conforms to the XDS-SD content profile specification.

<id/>

The ClinicalDocument/id element shall be present. The root attribute shall contain the oid for the document, in which case the extension attribute shall be empty, or an oid that scopes the set of possible unique values for the extention attribute, in which case the extension shall be populated with a globally unique identifier within the scope of the root oid.

The ClinicalDocument/code will in most cases be provided by the operator. Values for this code are dictated by the CDA R2 documentation, but are permissible to extend to fit the particular use case. Attributes code@code and code@codeSystem shall be present.

<title/>

The ClinicalDocument/title shall be present if known.

<effectiveTime/>

The ClinicalDocument/effectiveTime shall denote the time at which the original content was scanned. At a minimum, the time shall be precise to the day and shall include the time zone offset from GMT.

<confidentalityCody/>

The ClinicalDocument/confidentialityCode shall be assigned by the operator in accordance with the scanning facility policy. The notion or level of confidentiality in the header may not be the same as that in the Affinity Domain, but in certain cases could be used to derive a confidentiality value among those specified by the Affinity Domain. Attributes confidentialityCode@code and confidentialityCode@codeSystem shall be present.

<languageCode/>

The ClinicalDocument/languageCode, in accordance with the HL7 CDA R2 documentation, shall denote the language used in the character data of the wrapper CDA header. If the scanned content, when rendered, is in a language different than that of the header, the language context of the CDA will be overwritten at the body level (see ‎XDS-SD_OID#ClinicalDocument Body ClinicalDocument/component/nonXMLBody for an example). Attribute code@code shall be present. Attribute code@codeSystem shall be IETF (Internet Engineering Task Force) RFC 3066 in accordance with the HL7 CDA R2 documentation.

<recordTarget/>

The ClinicalDocument/recordTarget contains identifying information about the patient concerned in the original content. In many cases this will have to be supplied by the operator. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

  • The ClinicalDocument/recordTarget/patientRole/id element shall include both the root and the extension attributes. Refer back to ‎PCC_TF-2/Bindings for more details.
  • At least one ClinicalDocument/recordTarget/patientRole/addr element shall include at least the country subelement. The addr element has an unbounded upper limit on occurrences. It can, and should, be replicated to include additional addresses for a patient, each minimally specified by the country subelement.
  • At least one ClinicalDocument/recordTarget/patientRole/patient/name element shall be at least one given subelement and one family subelement.
  • The ClinicalDocument/recordTarget/patientRole/patient/administrativeGenderCode element shall be present.
  • The ClinicalDocument/recordTarget/patientRole/patient/birthTime element shall be present with precision to the year.
<custodian/>

The ClinicalDocument/custodian shall be present. Its context is left up to the scanning facility to refine in accordance with local policies and to reflect the entity responsible for the scanned content. In most cases this will be the scanning facility. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

  • The ClinicalDocument/assignedCustodian/representedOrganization/name shall be present.
  • At least one ClinicalDocument/assignedCustodian/representedOrganization/addr element shall include at least the country subelement.
<legalAuthenticator/>

The ClinicalDocument/legalAuthenticator may be present and its context is left up to the scanning facility to refine in accordance with local policies. All subelements retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

  • The ClinicalDocument/legalAuthenticator/assignedEntity/id element if known shall include both the root and the extension attributes. Refer back to ‎PCC_TF-2/Bindings for more details.
<documentationOf/>

This ClinicalDocument/documentationOf element is used to encode the date/time range of the original content. If the original content is representative of a single point in time then the endpoints of the date/time range shall be the same. Information regarding this date/time range shall be included, if it is known. In many cases this will have to be supplied by the operator. This profile does not restrict the documentationOf element beyond statements made in the HL7 CDA R2 documentation.

ClinicalDocument Header Content Modules

The table above lists the additional requirements (conformance statements) for this scanned document which are in the form of header content modules.

ClinicalDocument Header Example

<ClinicalDocument xmlns="urn:hl7-org:v3"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" classCode="DOCCLIN" moodCode="EVN" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">
  <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/>
  <templateId root="XDS-SD OID"/>
  <id root=“1.3.6.4.1.4.1.2835.2.7777”/>
  <code code=“34133-9”  codeSystem=“2.16.840.1.113883.6.1” 
codeSystemName=“LOINC” displayName=“SUMMARIZATION OF EPISODE NOTE”/>
  <title>Good Health Clinic Care Record Summary</title>
  <effectiveTime value=“20050329224411+0500”/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
  <languageCode code=“en-US”/>
  <recordTarget>
    <patientRole>
      <id extension="12345" root="2.16.840.1.113883.3.933"/>
      <addr>
        <streetAddressLine>17 Daws Rd.</streetAddressLine>
        <city>Blue Bell</city>
        <state>MA</state>
        <postalCode>02368</postalCode>
        <country>USA</country>
      </addr>
      <patient>
        <name>
          <prefix>Mrs.</prefix>
          <given>Ellen</given>
          <family>Ross</family>
        </name>
        <administrativeGenderCode code="F"
codeSystem="2.16.840.1.113883.5.1"/>
        <birthTime value="19600127"/>
      </patient>
   </patientRole>
  </recordTarget>
  <author>
    <templateId root="Original Author OID"/>
    <time value=“19990522”/>
    <assignedAuthor>
      <id extension=“11111111” root=“1.3.5.35.1.4436.7”/>
      <assignedPerson>
        <name>
          <prefix>Dr.</prefix>
          <given>Bernard</given>
          <family>Wiseman</family>
          <suffix>Sr.</suffix>
        </name>
      </assignedPerson>
    	<representedOrganization>
	   <id extension=“aaaaabbbbb”	root=“1.3.5.35.1.4436.7”/>
	   <name>Dr. Wiseman’s Clinic</name>
      </representedOrganization>
    </assignedAuthor>
  </author>
  <author>
    <templateId root="Scanner OID"/>
    <time value=“20050329224411+0500”/>
    <assignedAuthor>
      <id root=“1.3.6.4.1.4.1.2835.2.1234”/>
      <assignedAuthoringDevice>
<code code=“CAPTURE” displayName=“Image Capture” codeSystem=“  1.2.840.10008.2.16.4” /> 
<manufacturerModelName>SOME SCANNER NAME AND MODEL  </manufacturerModelName>
         <softwareName>SCAN SOFTWARE NAME v0.0</softwareName>
    	</assignedAuthoringDevice>
    	<representedOrganization>
	   <id root=“1.3.6.4.1.4.1.2835.2”/>
	   <name>SOME Scanning Facility</name>
         <addr>
           <streetAddressLine>21 North Ave</streetAddressLine>
           <city>Burlington</city>
           <state>MA</state>
           <postalCode>01803</postalCode>
           <country>USA</country>
         </addr>
      </representedOrganization>
   </assignedAuthor>
 </author>
  <dataEnterer>
    <templateId root="Scanner Operator OID"/>
    <time value=“20050329224411+0500”/>
    <assignedEntity>
      <id extension=“22222222” root=“1.3.6.4.1.4.1.2835.2”/>
      <assignedPerson>
        <name>
          <prefix>Mrs.</prefix>
          <given>Bernice</given>
          <family>Smith</family>
        </name>
      </assignedPerson>
    </assignedEntity>
  </dataEnterer>
  <custodian>
    <assignedCustodian>
      <representedCustodianOrganization>
	   <id root=“1.3.6.4.1.4.1.2835.2”/>
	   <name>SOME Scanning Facility</name>
         <addr>
           <streetAddressLine>21 North Ave</streetAddressLine>
           <city>Burlington</city>
           <state>MA</state>
           <postalCode>01803</postalCode>
           <country>USA</country>
         </addr>
      </representedCustodianOrganization>
    </assignedCustodian>
  </custodian>
  <legalAuthenticator>
    <time value=“19990522”/>
    <signatureCode code=“S”/>
    <assignedEntity>
      <id extension=“11111111” root=“1.3.5.35.1.4436.7”/>
      <assignedPerson>
        <name>
          <prefix>Dr.</prefix>
          <given>Bernard</given>
          <family>Wiseman</family>
          <suffix>Sr.</suffix>
        </name>
      </assignedPerson>
    </assignedEntity>
  </legalAuthenticator>
  <documentationOf>
    <serviceEvent >
      <effectiveTime>
        <low value=“19800127”/>
        <high value=“19990522”/>
      </effectiveTime>
    </serviceEvent>
  </documentationOf>
  <component>
    <nonXMLBody>

     ... scanned content here ...
    </nonXMLBody>
  </component>
</ClinicalDocument>

ClinicalDocument Body

This ClinicalDocument/component/nonXMLBody element shall be present and used to wrap the scanned content. The nonXMLBody element is guaranteed to be unique; thus the x-path to recover the scanned content is essentially fixed. All subelements of the nonXMLBody retain their original definition as defined by the HL7 CDA R2 specification, unless noted below.

  • If the human-readable language of the scanned content is different than that of the wrapper (specified in ClinicalDocument/languageCode), then ClinicalDocument/component/nonXMLBody/languageCode shall be present. Attribute code@code shall be present. Attribute code@codeSystem shall be IETF (Internet Engineering Task Force) RFC 3066 in accordance with the HL7 CDA R2 documentation.
  • The ClinicalDocument/component/nonXMLBody/text element shall be present and encoded using xs:base64Binary encoding. Its #CDATA will contain the scanned content.
    • ClinicalDocument/component/nonXMLBody/text@mediaType shall be “application/pdf” for PDF, or “text/plain” for plaintext.
    • ClinicalDocument/component/nonXMLBody/text@representation shall be present. The @representation for both PDF and plaintext scanned content will be “B64”, because this profile requires the base-64 encoding of both formats.


ClinicalDocument Body Example

Example (PDF scanned content is in the same language as the wrapper): 

<ClinicalDocument>
 ... CDA header content here ...
  <component>
    <nonXMLBody>
      <text mediaType=“application/pdf” representation=“B64”>
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB
Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx
a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO
BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu
K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0
...
SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48
RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx
MgolJUVPRgo=
     </text>
    </nonXMLBody>
  </component>
</ClinicalDocument>


Example (PDF scanned content is in a different language as the wrapper): 

<ClinicalDocument>
 ... CDA header content here ...
  <component>
    <nonXMLBody>
	<languageCode code=“zh-CN”/>
      <text mediaType=“application/pdf” representation=“B64”>
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0
ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB
Q/4/1L67TEEYme+9J1s3CMQQRm39NLuXg8H17gK89nN1N8eLAbZ2mmHXuql2QDVUhnZx
a5iBcyQtoMIUM7TZHbH5KZEVDgm//SSUswbFHx/JzBLeu5yYxOIzE8bPcRWqdaGDmcZO
BWc/9bfUNOPfOte44O9jxtcIKskqp0JZouJ5deYqeBn58ZmKtIU+2ptjqWQRJpGyrHDu
K7CXIe2be+/1DzXQP+RlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjAxCmVuZG9iago0
...
SW5mbyAyIDAgUgovSUQgWzxGNENDN0FFQjU0QjM2RkIyODNDNUMzMjQ3OUFEMjgzRj48
RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx
MgolJUVPRgo=
      </text>
    </nonXMLBody>
  </component>
</ClinicalDocument>
Retrieved from "http://wiki.ihe.net/index.php?title=XDS-SD_OID&oldid=19179"