Feature Friday - Creating document metadata

In our Feature Friday series today, we'll discuss how to create metadata while providing documents to an IHE XDS based health information exchange using the Founda Health platform.

Providing clinical documents

As defined by the IHE XDS profile, clinical information systems can make information available for sharing with other health information exchange participants by providing “documents” to a XDS Repository, relying on the repository to register the documents with a XDS Registry.?

Different from what you may expect when reading the word “document”, a document refers to a concept of clinical information that is persisted by a clinical source in a shape and form such that it remains available long after it was created. Whether that “shape or form” is a PDF, a structured clinical document, a bunch of images, or a snapshot from a database is not relevant. As it makes no sense for a registry to duplicate data already stored in a repository, a registry maintains a set of well-defined metadata for each provided (clinical) document. This metadata enables other systems to “discover” information previously provided for a patient through so-called “Registry Stored Query” transactions.?

Metadata is defined at three levels:

1. Document metadata
2. Submission metadata
3. Folder metadata

As documents are provided through “SubmissionSets” there is metadata describing the submission as well. Given that a XDS Registry can use “Folders” to organize documents that have some commonality there is also folder metadata. When multiple documents are submitted in a single SubmissionSet they are assumed to be (clinically) related. SubmissionSet metadata can be used to code such relationships. For example a set of images with their associated (clinical) report, or documents that are part of the same workflow (e.g referral or discharge).?

Although SubmissionSets and Folders have metadata, most XDS compatible systems (unfortunately) do not pay much attention to it. Document metadata carries more value as it is the information that is seen by users of applications supporting the XDS profile. Document metadata is just as you would expect: information that tells you what the document is about.?

Document metadata

Document metadata can be roughly divided into three categories:

1. Clinical (contextual) information. E.g. patient, author, timestamp, practice setting, (clinical) type of document, etc.
2. Technical (document) information. E.g. document size, hash, format, mimeType, etc.
3. Registry specific information. E.g. availability status, objectType, homeCommunityId, etc.

A full list of document metadata can be found in the XDS specifications.

The first category is the most important one as these metadata attributes tell something about the clinical information that is captured by (or in) the document. Examples are classCode, eventCode and typeCode. Three coded attributes that refer to the type of clinical information the document is about, and what clinical event led to the creation of it.?

Coded attributes in general are the most difficult to get right given the large variety of clinical information systems that are responsible for generating this metadata. For example, you may use the eventCode to reference the (DICOM) Imaging Procedure Code for a XDS(-I) document that references a DICOM Study. However, there is no guarantee that two radiology departments use the same procedure codes.?

This “challenge” is mostly solved by agreeing to a common terminology used by all participants of a health information exchange. A challenge that can be addressed by the Founda Health platform.

How does it work

As the majority of clinical information systems offer support for HL7v2 and/or DICOM protocols, our platform provides the capability to transform HL7v2 or DICOM “payloads” into XDS Documents, and derive metadata. Such transformations are referred to as “publication flows”.?

Publication flows

A publication flow combines the following:

• It defines a trigger event “message” (e.g and HL7 ORU message, a DICOM C-Store, or a html form post).
• It references “templates” that define how to transform information extracted from the message payload into metadata or content.
• It includes a number of (nested) “actions” that lead to the creation and publication of a XDS document, and document, submissionset, and/or folder metadata to a target XDS repository.

Templates are defined outside a publication flow, allowing a template to be (re)used in different flows.?

The diagram below shows how an event trigger leads to the creation and submission of a document.

Providing a Patient Consent Document

I’ll use an example of a publication flow that transforms an HL7 ADT A01 message into the submission of an IHE Basic Patient Privacy Consent (BPPC) document to explain how this works in the real world.?

The flow will be identified as "createConsentfromAdt".

<flow id="createConsentFromAdt">
  <provideSubmission outputName="provideOutput"
    submissionSetRef="adt2cdaSubmissionSet" xdsDestinationRef="xds" 
    select="true">
    <createDocument associationType="" documentRef="adtConsentDocument"
      documentUpdateRef="" id="" originalDocument="">
      <createXml encodeTextAsBase64="true"
       schema="file:/c:/forcare/cda/schemas/default/CDA.xsd" 
       schematron="file:/c:/forcare/cda/schematron/default/ihe_bppc/BPPC.sch"  
       schematronPhase="errors,warnings" 
       validate="true" 
       xslt="file:/c:/forcare/cda/stylesheets/default/cda-hl7-adt-bppc.xslt"/>
    </createDocument>
  </provideSubmission>
</flow>        

Next this publication flow is associated with a HL7v2 ADT^A01 trigger event.

<flow flowId="createConsentFromAdt" select="#{'ADT'.equals(message['MSH.9.1']) && 'A01'.equals(message['MSH.9.2'])}" splitPattern=""/>        

?The <provideSubmission> and <createDocument> actions in the flow configuration refer to metadata templates “adt2cdaSubmissionSet”, and “adtConsentDocument“ respectively. The actual BPPC document is created through the <createXML> action.? This configuration snippet defines that a HL7 CDA document is created conforming to the IHE BPPC schematron. It is submitted as a base64 encoded file to an “xdsDestination” defined elsewhere in the configuration.?

The attribute “associationType” allows for replacing, deprecating or transforming previously provided documents as defined by the IHE XDS registry model.?

The "adtConsentDocument" template includes all non-computational attributes and looks like (simplified):

<documentTemplate id="adtConsentDocument">
 <authors>
   <authorPerson value=""/>
   <authorRole value=""/>
   <authorSpecialty value=""/>
   <authorInstitution value=""/>
   <authorTelecommunication value=""/>
 </authors>
 <classCode>
   <code />
   <defaultCode />
 </classCode>
 <confidentialityCodes />
 <healthcareFacilityTypeCode />
 <languageCode value="en-US"/>
 <legalAuthenticator value=""/>
 <practiceSettingCode />
 <typeCode />
 <referenceIds>
   <referenceId />
 </referenceIds>
 <title value=""/>
 <comments value=""/>
 <creationTime value=""/>
 <serviceStartTime value=""/>
 <serviceStopTime value=""/>
 <formatCode />
 <mimeType value=""/>
 <repositoryUniqueId value=""/>
 <eventCodes />
 <custom>
  <slot name="" value=""/>
 </custom>
</documentTemplate>        

All elements use EL-expressions to set a value that is based on data extracted from the trigger message. For example an expression “#{message['PID.3']}” extracts the third field in the PID segment from an HL7 message. An expression “#{valueOrDefault(toXCN(concat('^', dicom['00080090'])), toXCN('^Unknown^author'))}” extracts the value of DICOM tag 0008,0090 (Referring Physician’s Name), and transforms it to a XCN data type. If the DICOM tag is absent or empty a default value is set.

All coded elements (classCode, confidentialityCodes, etc.) have the ability to define a default code when no code can be derived from the original message that triggered the flow.?

The following example shows how typeCode is extracted from the first item in the DICOM Requested Procedure Code Sequence. If this sequence is not existing the defaultCode is used.?

<typeCode>
  <code 
    codingScheme="#{dicom['00321064[1]/00080102']}"
    displayName="#{dicom['00321064[1]/00080103']}"
    value="#{dicom['00321064[1]/00080100']}"/>
  <defaultCode 
    codingScheme="2.16.840.1.113883.6.1" 
    displayName="Diagnostic Imaging Study Report" 
    value="18748-4"/>
</typeCode>        

A unique feature is the creation of custom slots that are supported by a XDS registry. The <slot> element allows adding such custom defined slots.?

The example below adds a custom slot that refers to the documentTemplate and publication flor that were used to create the document and its metadata. This helps to trace metadata errors that surface in a document consumer back to the template and publication flow that were used for the document’s submission.

<custom>
  <slot name="urn:x-forcare:docTrace" value="#{concat('dicom source id: ', 
    dicomSource.id, ' - flow id: ', flow.id, ' - documentTemplate id: ', 
    docTemplate.id)}"/>
</custom>        

Summary

The document creation and submission functionality of the Founda Health platform enables providers to submit almost any type of XDS document to a IHE XDS-based health information exchange. Whether you need to create, update or replace XDS documents based on HL7v2 or DICOM event triggers, the Founda Health platform provides functionality to support your requirements.

If you like to know more about Founda Health solutions for Health Information Exchange in general, or Image Exchange in particular please check out our website or contact us for more information.