MHD-rev2-vol-3

From IHE Wiki
Jump to: navigation, search

Contents

HL7/FHIR Mapping Overview

Many of the Document Sharing concepts defined in IHE profiles are directly supported by FHIR. FHIR has the concept of a 80/20 rule where they are willing to customize FHIR to support 80% of the features and leave the last 20% to use the defined FHIR extension mechanisms. IHE Document Sharing defines some attributes using the extension mechanism.

FHIR Servers

There is also a difference in architecture between IHE Document Sharing and HL7 FHIR. Looking at XDS there are two actors that would be typically thought of as servers, the Document Repository and Document Registry. In FHIR these would be considered two FHIR servers which are customized to maintain different content and provide different processing. This is not an issue for the MHD profile since MHD focuses on extensions to the Document Source and Document Consumer areas of the profile but it may be important later.

FHIR Resources

The FHIR specification documents pre-defined objects that are to be aggregated to construct a health record. These objects are called Resources. The construct of a profile based on FHIR is to define aggregations and extensions to these objects. The primary resources to support document sharing are the DocumentReference and DocumentManifest resources which correspond to the IHE Document Sharing DocumentEntry and SubmissionSet objects.

Traditional FHIR is based on a REST-style transport where each resource is submitted or retrieved separately. This fits poorly with the existing IHE transactions used in document sharing for submitting content. FHIR also defines a composite submission based on the ATOM protocol that is similar to the MTOM protocol used by existing document sharing profiles.

Resource Extensions

FHIR resources can be extended. An extension is a way to add content to a resource beyond its basic definition.

Contained Resources

This section needs rewriting to distinguish between Resources nested inside other Resources (which is needed for constructing DocumentEntry etc.) and Resources nested inside Atom Feeds (which is needed for constructing the equivalent of RegistryObjectList).

While the FHIR resources DocumentReference and DocumentManifest map to the IHE definitions of DocumentEntry and SubmissionSet, there are differences in the specification of some attributes. IHE defines patient and author information as attributes of the DocumentEntry and SubmissionSet objects where FHIR defines these as separate resources. FHIR resources are never nested, they are referenced so it is not possible to build up a DocumentEntry in FHIR with the same nesting rules. Instead a DocumentEntry maps to a composite of a DocumentReference resource, zero or more Practitioner resources representing the authors, and a Patient resource holding the patient information. This composite of FHIR resources, equivalent to a DocumentEntry, is constructed using a technique in FHIR called contained resources. This is a special set of rules for imposing a nested style of resource composition in a specification that is based on reference and not composition. This submission style can be used with the ATOM protocol but not the REST protocol.

To accommodate the more composed style of IHE Document Sharing objects, FHIR allows normally separate, referenced objects to be bundled into a FHIR resource in a contained object. In this partial example:

<DocumentReference>
   <contained>
      <Patient>
         ...
      </Patient>
   </contained>
   <contained>
      <Practitioner/>
   </contained>
</DocumentReference>

The Patient element

ATOM Feed

The ATOM Feed is used as the bundling mechanism for submissions. It is the only mechanism in FHIR that allows a collection of objects to be sent and have have inter-object relationships coded. From an IHE Document Sharing perspective this accomplishes two things. First it allows DocumentManifest and DocumentReference objects to be bundled together. This is accomplished in ebRIM using the RegistryObjectList object. Second, the FHIR specification requires a different metadata construction style than ebRIM. With ebRIM the document specifics, the author specifics, and the patient specifics are all bundled into one object. This happens with the SubmissionSet, DocumentEntry, and Folder objects. In FHIR the author and patient information is normally submitted as separate objects. A document submission would reference these objects, not include them.

References to other objects

IHE Document Sharing, originally defined on the OASIS ebXML Registry standard, uses independent Association objects to link other objects. The Association objects contain a from-reference a to-reference and a type indicating the purpose of the linkage. Associations are first class objects; they can contain other metadata attributes to refine the meaning of the references they provide.

FHIR references are not built from independent objects but from link attributes defined within the linked object. These references are single direction, an object containing a reference to another object.

Major object types

The major objects defined by IHE Document Sharing map to FHIR resources as follows.

Document Sharing Object FHIR Resource
DocumentEntry DocumentReference
SubmissionSet DocumentManifest
Folder List
Association Embedded reference

Open Issues

MHD001 - Current metadata is referenced as Document Sharing ... Good reference?

MHD002 - In our current binding we use the term DocumentEntry. This maps to an ExtrinsicObject in ebRIM. At the moment in MHD I refer to the equivalent in the FHIR binding as DocumentReference. What wording style is going to move forward? Continue to use DocumentEntry to mean either ExtrinsicObject or DocumentReference depending on binding or use FHIR specific language everywhere?

MHD003 - The volume 3 material is being written as a reference and not a tutorial. Tutorial material should be kept separate.

MHD004 - I am excluding FHIR example XML (and JSON) from our document instead referencing specific pages on the HL7 FHIR website. This will create a lot of web references in the PDF.

MHD005 - The MHD Document Recipient must map Practitioner, Patient, and RelatedPerson into Document Sharing authorPerson elements. The MHD Document Responder will have to choose how it converts authorPerson into one of Practitioner, Patient, and RelatedPerson. One of the following choices must be made in writing the profile: accept the mapping of RelatedPerson to authorPerson (at the MHD Document Recipient) to Practitioner (at the MHD Document Responder) (for example) or add new annotations to the ebRIM format so these can be distinguished. Does the XCN data type allow for the coding of the distinction?

MHD006 - the mapping of classCode and typeCode into the FHIR is confusing. The HL7 interpretation of XDS is that typeCode maps into the FHIR element class and classCode maps into ??? But DocumentReference contains both type [1..1] and class [0..1] elements. I believe we should override the HL7 opinion and map typeCode into type and classCode into class. This leaves one problem at the MHD Document Recipient. An inbound FHIR DocumentReference cannot be translated into a DocumentEntry if the DocumentReference is missing the class element (cardinality [0..1] since classCode is [1..1].

MHD007 - Mapping serviceStartTime and serviceStopTime into context/period is not a real good match. In FHIR:

  • If the start element is missing, the start of the period is not known. If the end element is missing, it means that the period is ongoing.
  • start/stop times are with inclusive boundaries
  • It is not clear that these times in FHIR apply to the “service”. They can apply to many things. It is unclear whether being bound inside the context element fixes the semantics.

MHD008 - The current ebRIM binding allows for coding a person as legalAuthenticator (XCN format) where FHIR allows for coding either Practitioner or Organization. This causes a potential loss of information at the MHD Document Recipient since an Organization cannot be coded given the Document Sharing information model.

MHD009 - Attributes patientId, sourcePatientId, sourcePatientInfo are coded as three separate attributes in the Document Sharing information model. In FHIR they are all part of the Patient structure. Note that in the Document Sharing information model there are two codings of sourcePatientIdentifer: the separate attribute and a part of sourcePatientInfo. I have no idea why but that’s the way it is. A translation between ebRIM and FHIR would require a choice as to which one to use if they are different.

MHD010 - practiceSettingCode - I am clueless where to map this. The FHIR element custodian may be appropriate but it is a stretch.

Needs to be defined as an extension.

MHD011 - referenceId needs a system name URI to label that FHIR Identifier

MHD012 - XDS has both title and description attributes. FHIR has only description. I have mapped DocumentEntry.title into DocumentReference.description and left out DocumentEntry.description. To add it we would have to add an extension.


MHD014 - DocumentEntry.uniqueId has format OID or OID with extension. In FHIR this maps to MasterIdentifier. While OID maps well we need to identify how to map OID with extension.

MHD015 - SubmissionSet can include a Folder though a HasMember Association. The DocumentManifest resource can only reference DocumentReference|Binary|Media as types of its content, the equivalent to a HasMember Association.

MHD015 - Should the Volume 3 material include side by side display of ebRIM and FHIR bindings for identical information?

MHD016 - Time precision in FHIR is different. It always requires precision to the second where current XDS allows any precision.

MHD017 - Add a Semantic Mapping section to attributes where the current XDS semantics cannot be carried through FHIR.

MHD019 - In FHIR all extensions are defined by a dereferenceable URL points to the documentation for the extension in the Profile. So far I have coded these as http://ihe.net/fhir/Profile/XDS/attribute-name. We need to decided on the proper value for this URL.

MHD020 - The Document Sharing semantics of inclusion of a DocumentEntry in a SubmissionSet by Reference cannot be coded in FHIR.

MHD021 - DocumentEntry.formatCode is a code. DocumentReference.format is a URI. For now I am showing the formatCode.code value (without the code system).

MHD022 - SubmissionSet.contentTypeCode is a real mess. IHE documentation says it identifies the clinical activity. FHIR DocumentManifest.type says it identifies the type of document set. The Connectathon feedback is that folks are using it identify document types. For now I have specified SubmissionSet.contentTypeCode as an extension and have not used DocumentManifest.type. This has to be revisited.

new things to incorporate:

MHD005 - reference HL7 CP relating
MHD007 - does existing CP help or hurt?
appendix defining mapping exceptions
class - short definition of classCode 
hash - FHIR - base64 encoding? - link to FHIR CP - email from John

MHD023 - This profile defines several extensions. The FHIR standards requires the URL defined in the extension element to reference a Resource profile (XML document) that can be interrogated. For now we have used a base URL that cannot be deference. This is a placeholder until we have an actual server to support this functionality. Better intermediary solutions might be to use the IHE wiki (intended for HTML documents not XML documents) or the ihexds.nist.gov site that I control (not an IHE owned site). I believe the final/correct solution to be ihe.net but profile developers do not have direct access to this site to maintain the content so it is not a great solution either. For now we do not have resource profiles to publish. When we develop these we will need to solve this.

Closed Issues

MHD013 - What is the goal of the MHD profile? This was originally documented under the DocumentEntry.URI attribute semantic mappings section.

For now I am working to detail the MHD environment which is a hybrid FHIR environment tailored to XDS.

Background

This DocumentEntry attribute is used to identify the relevant document repository in various Document Sharing profiles. It is not needed in the FHIR environment. It is used in a SOAP environment to identify the repository holding the document. But, since the possibility of translation from SOAP-based binding to FHIR binding back to SOAP-based binding is possible, it needs to be carried forward to allow this possible future translation. In the FHIR environment it is coded as an extension.

DocumentEntry.URI is only used in the XDM profile for the DocumentEntry to reference the Document on the media. This is semantically similar to the FHIR approach of DocumentReference.location holding a URI that is used in a HTTP GET to retrieve the document contents.

In moving between XDS and FHIR based environments there are two possible semantic rule sets. The first choice is to enforce the XDS environment but with FHIR coding of messages. This implies that the MHD Document Source and MDH Document Consumer are not constructed by FHIR rules but instead by XDS/FHIR rules. This choice makes the MHD Document Recipient easier to interface to the XDS Document Source and the MHD Document Responder easier to interface to the XDS Document Consumer but the construction of the MHD Document Source and MHD Document Consumer more complex because they must conform to both XDS and FHIR rules.

The other choice is to have the MHD Document Source and MHD Document Consumer be constructed purely by FHIR rules. This places the complexity in the MHD Document Recipient and MHD Document Responder.

Focusing beyond where the complexity belongs, what is the purpose of the MHD profile? Is it to adapt XDS to mobile devices using FHIR technology where needed or allow the construction of an XDS/FHIR gateway (the MHD Document Recipient and MHD Document Responder) between XDS and FHIR document sharing environments?

What attributes are affected by this decision? All attributes that we would put in FHIR contained areas such as Patient information, Author information, DocumentEntry.repositoryUniqueId, DocumentEntry.URI. In a natural FHIR environment the patient and author information would come from references to Patient and Practitioner resources stored on existing FHIR servers. In an XDS-centric environment this information would be included in contained resources.

Resolution - Since our primary customers are the vendors etc. that have already implemented XDS and want to extend into mobile apps, I am moving forward with the hybrid FHIR environment tailored to XDS. If we purse a pure FHIR binding it will be defined in a separate later work item.

MHD018 - How can we translate entryUUID into FHIR?

Resolution - Force the FHIR resource instance ID (also called the permanent ID) to be in UUID format. See DocumentEntry.entryUUID for details.

MHD Server

From the perspective of the MHD Document Source and the MHD Document Consumer, the rest of the MHD and XDS actors form a FHIR server that uses a dialect of FHIR specified by the MHD profile. Specifically it is the transactions specified by MHD, Put Document Dossier [ITI-65], Find Document Dossier [ITI-67], Get Document Dossier [ITI-66], and Get Document [ITI-68] that use this MHD dialect. For convenience this FHIR server will be referenced as an MHD server.

MHD server diagram.jpg

The overriding goal of MHD is to move objects between the MHD and XDS environment without loss of information. A key aspect is the use of a compatible form of object/resource addressing. In the XDS environment objects are identified by UUID format IDs. In FHIR the ID can utilize several string-based formats including OID and UUID [reference]. Therefore, all FHIR logical IDs carried by MHD transactions shall be in UUID format.

The resulting FHIR resource URL looks like

http://example.com/mhd/DocumentReference/a54d6aa5-d40d-43f9-88c5-b4633d873a45

where DocumentReference indicates the object type and a54d6aa5-d40d-43f9-88c5-b4633d873a45 is the logical ID of the object in UUID format without the urn:uuid: prefix.

Metadata Attribute Mapping

This section only offers guidance on how to code FHIR to meet the existing IHE Document Sharing requirement. See Volume 3 of the ITI Technical Framework section 4.2.3 for the IHE Document sharing requirements.

Coding Rules

Coded Concept

This is an MHD extension to ITI-TF:Vol 3 4.2.3.1.2 Creating Coded Attributes. An example coded attribute (FHIR Coded Concept) is:

<coding>
    <system value="urn:oid:2.16.840.1.113883.6.1"/>
    <code value="28651-8"/>
    <display value="Nurse Transfer note"/>
</coding>

When the code system shall be coded as a URI. The coding is shown above for OIDs.

FHIR to ebRIM overview

DocumentReference

FHIR Model DocumentEntry Model
DocumentReference DocumentEntry
Contained Practitioner or Device DocumentEntry.author
DocumentReference.status DocumentEntry.availabilityStatus
DocumentReference.class DocumentEntry.classCode
DocumentReference.text DocumentEntry.comments
DocumentReference.confidentiality DocumentEntry.confidentialityCode
DocumentReference.created DocumentEntry.creationTime
DocumentReference logicalID (coded in bundle) DocumentEntry.entryUUID
DocumentReference.format DocumentEntry.formatCode
DocumentReference.hash DocumentEntry.hash
DocumentReference.context.event DocumentEntry.eventCodeList
DocumentReference.context.period DocumentEntry.serviceStartTime, DocumentEntry.serviceStopTime
DocumentReference.context.facilityType DocumentEntry.healthcareFacilityTypeCode
DocumentReference.primaryLanguage DocumentEntry.languageCode
Contained Practitioner or Organization DocumentEntry.legalAuthenticator
DocumentReference.mimeType DocumentEntry.mimeType
Contained Patient DocumentEntry.patientId, DocumentEntry.sourcePatientId, DocumentEntry.sourcePatientInfo
practiceSettingCode extension DocumentEntry.practiceSettingCode
DocumentReference.identifier DocumentEntry.referenceIdList
DocumentReference.size DocumentEntry.size
DocumentReference.description DocumentEntry.title
DocumentReference.type DocumentEntry.typeCode
DocumentReference.masterIdentifier DocumentEntry.uniqueId

SubmissionSet

TBD

Folder

TBD

DocumentEntry

IHE Document Sharing DocumentEntry corresponds to FHIR DocumentReference.

The text element represents an HTML rendition of the DocumentReference. This example shows that the HTML has been generated. The other possible values for status are documented here.

<DocumentReference>
   <text>
      <status value="generated"/>
      <div  xmlns="http://www.w3.org/1999/xhtml">
      </div>
   </text>
 </DocumentReference>

The attributes of the DocumentReference are nested inside the DocumentReference element.

DocumentEntry.author attribute

The Document Sharing information model requires at least an authorPerson, authorTelecommunication, or authorInstitution sub-attribute shall be present when the author attribute is included in the DocumentEntry metadata. This implies that authorRole and authorSpeciality can only be coded if one of authorPerson, authorTelecommunication, or authorInstitution is coded. Furthermore, authorPerson can be coded as either a human or machine author. The following mappings shall be used between ebRIM binding and FHIR binding for author as human Practitioner:

DocumentEntry Model FHIR resource
human Practitioner or Patient or RelatedPerson
device Device
telecom Can only be coded as an element inside Practitioner, Patient, or RelatedPerson
institution Can only be coded as an organization element inside Practitioner, Patient, and Device. It cannot be coded as part of RelatedPerson.

Note: The MHD Document Recipient must map Practitioner, Patient, and RelatedPerson into Document Sharing authorPerson elements. The MHD Document Responder will have to choose how it converts authorPerson into one of Practitioner, Patient, and RelatedPerson. The XCN style coding on the DocumentEntry.author.authorPerson does not distinguish between Practitioner, Patient, or RelatedPerson.

Since author is implemented by referencing an independent resource in FHIR and Document Sharing information model requires that it be included in the submission, it is coded in the contained section of the DocumentReference element. An example of this coding in both XML and JSON can be found here.

The Document Sharing authorPerson sub-attribute is coded in HL7 V2 XCN format. (see ITI TF-3:Table 4.2.3.1.7-2 for details)

sub-attribute HL7 V2 format Example & field being mapped FHIR Field mapping
authorPerson XCN 11375^Welby^Marcus^J^Jr. MD^Dr^^^&1.2.840.113619.6.197&ISO
Component 1 (identifier) Practitioner/identifier/value/@value

= 11375

Component 9 (Assigning Authority) Practitioner/identifier/system/@value

= urn:oid:1.2.840.113619.6.197

Component 2 (Last Name) Practitioner/name/family/@value

= Welby

Component 3 (First Name) Practitioner/name/given/@value

= Marcus

Component 5 (Suffix) Practitioner/name/suffix/@value

= Jr. MD

authorInstitution XON Some Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45
Component 1 (Organization Name) Practitioner/organization/name/@value

= Some Hospital

Component 10 (Organization Identifier) Practitioner/organization/identifier/@value

= 1.2.3.4.5.6.7.8.9.1789.45

Some Hospital^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^45
Component 1 (Organization Name) Practitioner/organization/name/@value

= Some Hospital

Component 10 (Organization Identifier - non-OID) Practitioner/organization/identifier/value/@value

= 45

Component 6.2 (Assigning Authority) Practitioner/organization/identifier/system/@value

= urn:oid:1.2.3.4.5.6.7.8.9.1789

authorRole Role Name Practitioner/role/text/@value

= Role Name

authorSpecialty Specialty Name Practitioner/specialty/text/@value

= Specialty Name

authorTelecommunication XTN ^^Internet^john.doe@healthcare.example.org
Component 3 (type) Practitioner/telecom/system/@value

= email

Component 4 (email address) Practitioner/telecom/value/@value

= john.doe@healthcare.example.org

Semantic Mapping

DocumentEntry allows multiple authorInstitutions. FHIR Practitioner resource only allows a single Organization.

DocumentEntry.availabilityStatus attribute

DocumentEntry.availabilityStatus is coded as the FHIR element DocumentReference.status with the following value mapping:

ebRIM FHIR
urn:oasis:names:tc:ebxml-regrep:StatusType:Approved current
urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated superceeded

For example:

<status value="current"/>

In Document Sharing this is optional on submission. In FHIR it is required on submission.

DocumentEntry.classCode attribute

DocumentEntry.classCode is mapped into the FHIR element DocumentReference.class. The following minimal coding shall be provided:

<class>
    <coding>
        <system value="coding scheme value"/>
        <code value="code value"/>
        <display value="display name"/>
    </coding>
</class>

Where system defines the coding scheme the code is taken from. This is frequently an OID although FHIR prefers dereference-able URIs. Code is the code value taken from the coding scheme. Display is the display name for the code provided.

So the following DocumentEntry.classCode

<Classification
    classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
    classifiedObject="Document01" nodeRepresentation="History"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
    id="id_3">
    <Slot name="codingScheme">
        <ValueList>
            <Value>Connect-a-thon classCodes</Value>
        </ValueList>
    </Slot>
    <Name>
        <LocalizedString value="History and Physical"/>
    </Name>
</Classification>

would be coded in FHIR as

<class>
    <coding>
        <system value="Connect-a-thon classCodes"/>
        <code value="History"/>
        <display value="History and Physical"/>
    </coding>
</class>

Semantic Mapping

In FHIR it is not possible to code the display name in multiple languages.

DocumentEntry.comments attribute

DocumentEntry.comments does not map to any FHIR attribute. It must be coded as an extension.

  <extension url=“http://ihe.net/fhir/Profile/XDS/extensions#comments”>
    <valueString value=“Text of the comment”/>
  </extension>

Semantic Mapping

In ebRIM this field can be coded concurrently in multiple languages. In FHIR this is not available.

DocumentEntry.confidentialityCode attribute

DocumentEntry.confidentialityCode is mapped into the FHIR element DocumentReference.confidentiality. The following minimal coding shall be provided:

<confidentiality>
    <coding>
        <system value="coding scheme value"/>
        <code value="code value"/>
        <display value="display name"/>
    </coding>
</confidentiality>

Where system defines the coding scheme the code is taken from. This is frequently an OID although FHIR prefers dereference-able URIs. Code is the code value taken from the coding scheme. Display is the display name for the code provided.

DocumentEntry.creationTime attribute

DocumentEntry.creationTime attribute is mapped to the FHIR element DocumentReference.created.

Example coding is:

<created value="2005-12-24T09:35:00"/>

Semantic Mapping

The mapping is discussed here.

DocumentEntry.entryUUID attribute

The DocumentEntry.entryUUID attribute maps to the logical ID assigned to a DocumentReference resource. In FHIR, logical IDs are considered metadata of a resource and are coded outside of the resource. In XDS the entryUUID is coded inside the DocumentEntry. The logical ID assigned to a DocumentReference shall be in UUID format without the urn:uuid: prefix. When translating from Document Sharing to MHD, the DocumentEntry.entryUUID shall be mapped to the DocumentReference logical ID after removing the urn:uuid: prefix. When translating from MHD to XDS, the DocumentReference logical ID shall be mapped to the DocumentEntry.entryUUID after adding the urn:uuid: prefix.

Need reference to documentation of the atom feed where this attribute is coded.

DocumentEntry.eventCodeList attribute

This attribute is coded inside the context element as the DocumentReference.event element.

  <context>
    <event>
      <coding>
        <system value="http://ihe.net/xds/connectathon/eventCodes"/>
        <code value="T-D8200"/>
        <display value="Arm"/>
      </coding>
    </event>
  </context>

DocumentEntry.formatCode attribute

DocumentEntry.formatCode is mapped into the FHIR element DocumentReference.format. The following minimal coding shall be provided:

<format value="code value as URI"/>

Semantic Mapping

In XDS the formatCode is a coded term (code, codingScheme, displayName) but in FHIR it is URI. There is a potential loss of information going from Document Sharing to FHIR.

DocumentEntry.hash attribute

DocumentEntry.hash is mapped into the FHIR element DocumentReference.hash. The following coding shall be used:

<hash value="e543712c0e10501972de13a5bfcbe826c49feb75"/>

DocumentEntry.healthcareFacilityTypeCode attribute

This attribute is coded inside the context element as the DocumentReference.facilityType elements.

  <context>
    <facilityType>
      <coding>
        <system value="http://www.ihe.net/xds/connectathon/healthcareFacilityTypeCodes"/>
        <code value="Outpatient"/>
        <display value="Outpatient"/>
      </coding>
    </facilityType>
  </context>

DocumentEntry.homeCommunityId attribute

DocumentEntry.homeCommunityId does not map to any FHIR attribute. It shall be coded as an extension.

  <extension url=“http://ihe.net/fhir/Profile/XDS/extensions#homeCommunityId”>
     <valueString value=“urn:oid:1.2.334483.3.337395864.7”/>
  </extension>

DocumentEntry.languageCode attribute

DocumentEntry.languageCode is mapped into the FHIR element DocumentReference.primaryLanguage. The following coding shall be used:

<primaryLanguage value="en-US"/>

DocumentEntry.legalAuthenticator attribute

DocumentEntry.legalAuthenticator is mapped to the FHIR element DocumentReference.authenticator. XDS specifies the coding in XCN format. FHIR allows for coding either DocumentReference.Practitioner or DocumentReference.Organization. In the translation from XDS to MHD, the XCN format DocumentEntry.legalAuthenticator shall be translated into the FHIR Practitioner resource. In the translation from MHD to XDS there may be information loss since Practitioner can include information that cannot be coded in XCN.

The following coding shall be used:

<DocumentReference>
    <contained>
        <Practitioner id="auth1"/>
    </contained>

    ...

    <authenticator>
        <reference value="#auth1"/>
    </authenticator>
</DocumentReference>

Since Practitioner is a separate FHIR resource it cannot be nested inside authenticator. It must be referenced. Since the Document Sharing information model requires each submission be complete with no external references, the Practitioner resource must be coded as part of the DocumentReference in a contained element.

DocumentEntry.mimeType attribute

DocumentEntry.mimeType is mapped into the FHIR element DocumentReference.mimeType. The following coding shall be used:

<mimeType value="text/plain"/>

DocumentEntry.patientId attribute

DocumentEntry.patientId attribute is mapped into the FHIR resource DocumentReference.Patient.

Current XDS:

1234^^^&1.3.6.1.4.1.21367.2005.3.7&ISO

FHIR coding:

<DocumentReference>
    <contained>
        <Patient id="patient">
          <identifier>
            <system value=“urn:oid:1.3.6.1.4.1.21367.2005.3.7”/>
            <value value=“1234”/>
          </identifier>
        </Patient>
    </contained>

    ...

    <subject>
        <reference value="#patient"/>
    </subject>
</DocumentReference>

Patient is a separate FHIR resource so it cannot be nested inside DocumentReference. It must be referenced. Since the Document Sharing information model requires each submission be complete with no external references outside the submission, the Patient resource must be coded as part of the DocumentReference in a contained element and referenced from the subject element.

A FHIR Patient resource can carry several Patient IDs, differentiated by a use element. An example is:

                    <Patient id="patient">
                        <identifier>
                            <use value="official"/>
                            <system value="urn:oid:1.3.6.1.4.1.21367.2005.3.7"/>
                            <value value="6578946"/>
                        </identifier>
                        <identifier>
                            <use value="usual"/>
                            <system value="urn:oid:1.2.3"/>
                            <value value="6578946"/>
                        </identifier>
                    </Patient>

If the Patient resource contains multiple identifiers then they must carry the use element and one must be labeled as official as shown above.

DocumentEntry.repositoryUniqueId

The MHD Profile does not directly rely on the repositoryUniqueId attribute. It is used only by the underlying XDS actors that support MHD.

DocumentEntry.serviceStartTime attribute

This attribute is coded inside the context element as the DocumentReference.period.start element.

This attribute maintains the original XDS semantics.

  <context>
    <period>
      <start value="2004-12-23T08:00:00"/>
      <end value="2004-12-23T08:01:00"/>
    </period>
  </context>

DocumentEntry.serviceStopTime attribute

This attribute is coded inside the context element as the DocumentReference.period.end element.

This attribute maintains the original XDS semantics.

  <context>
    <period>
      <start value="2004-12-23T08:00:00"/>
      <end value="2004-12-23T08:01:00"/>
    </period>
  </context>


DocumentEntry.sourcePatientId and DocumentEntry.sourcePatientInfo attributes

These attributes are discussed together because of their overlapping contents. DocumentEntry.sourcePatientId, DocumentEntry.sourcePatientInfo attributes are mapped into the FHIR resource DocumentReference.Patient. The DocumentEntry.patientId attribute is also mapped into a Patient resource. While these two Patient resources reference the same human patient, they represent two different records of information about the patient. For example the patient contains the Affinity Domain patient ID and the sourcePatient contains a sometimes different local patient ID. Because these represent separate records they are coded as two separate Patient resources in the DocumentReference.

Attributes DocumentEntry.sourcePatientId, DocumentEntry.sourcePatientInfo are coded as three separate attributes in the Document Sharing information model. DocumentEntry.sourcePatientId is also redundant since its value is also carried inside DocumentEntry.sourcePatientInfo. The translation from XDS to MHD is undefined if DocumentEntry.sourcePatientId is different from DocumentEntry.sourcePatientInfo.patientId.

Current XDS:

PID-3|DTP-1^^^&1.3.6.1.4.1.21367.2005.3.7&ISO
PID-5|Smith^George^^^
PID-7|19650120 
PID-8|M 
PID-11|100 Main St^^BURLINGTON^MA^01803^USA

FHIR coding:

<DocumentReference>
    <extension url=“http://ihe.net/fhir/Profile/XDS/extensions#sourcePatient”>
        <valueResource>
          <reference value=“#sourcePatient”/>
        </valueResource>
    </extension>

 ...

    <contained>
        <Patient id="sourcePatient">
          <identifier>
            <value value=“DTP-1”/>
            <system value=“urn:oid:1.3.6.1.4.1.21367.2005.3.7”/>
          </identifier>
          <name>
             <family value="Smith"/>
             <given value="George"/>
          </name>
          <gender>
             <coding>
                <system value="http://hl7.org/fhir/v3/AdministrativeGender"/>
                <code value="M"/>
                <display value="Male"/>
             </coding>
          </gender>
          <birthDate value="2004-12-23T08:00:00"/>
          <address>
             <text value="100 Main St BURLINGTON MA 01803 USA"/>
          </address> 
        </Patient
    </contained>
    ...

</DocumentReference>

Patient is a separate FHIR resource so it cannot be nested inside DocumentReference. It must be referenced. Since the Document Sharing information model requires each submission be complete with no external references outside the submission, the Patient resource must be coded as part of the DocumentReference in a contained element. The DocumentReference include only a single Patient resource so this Patient resource representing the sourcePatient is coded as an extension.

In XDS having two patient information references is natural. Not so in FHIR. This leads the MHD adaptation of FHIR to include two Patient resources as contained objects. One defines the coding of the Affinity Domain patient information, really just the Patient ID. The second defines the Source Patient information. This does not semantically fit into FHIR so it is defined not only as a contained object but also as an extension as shown in the above example.

DocumentEntry.practiceSettingCode attribute

DocumentEntry.practiceSettingCode does not map into any predefined element in DocumentReference so it shall be coded as an extension.

<extension url=“http://ihe.net/fhir/Profile/XDS/extensions#practiceSettingCode”>
    <valueCoding>
        <system value="coding scheme value"/>
        <code value="code value"/>
        <display value="display name"/>
    </valueCoding>
</extension>

DocumentEntry.referenceIdList

DocumentEntry.referenceIdList is mapped into the FHIR element DocumentReference.identifier. The following minimal coding shall be provided:

<identifier>
    <value value="2013001^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:accession"/>
    <system value="URI indicating referenceIdList"/>
</identifier>

DocumentEntry.size attribute

DocumentEntry.size is mapped into the FHIR element DocumentReference.size. The following coding shall be used:

<size value="10234"/>

DocumentEntry.title attribute

DocumentEntry.title is mapped into the FHIR element DocumentReference.description. The following coding shall be used:

<description value="Post-Op Exam"/>

DocumentEntry.typeCode attribute

DocumentEntry.typeCode is mapped into the FHIR element DocumentReference.type. The following minimal coding shall be provided:

<type>
    <coding>
        <system value="coding scheme value"/>
        <code value="code value"/>
        <display value="display name"/>
    </coding>
</type>

Where system defines the coding scheme the code is taken from. This is frequently an OID although FHIR prefers dereference-able URIs. Code is the code value taken from the coding scheme. Display is the display name for the code provided.

DocumentEntry.uniqueId

DocumentEntry.uniqueId is mapped into the FHIR element DocumentReference.masterIdentifier. In XDS it is coded without the urn:oid: prefix. For the MHD binding the prefix shall be coded. It shall be coded as:

<masterIdentifier>
    <system value="urn:ietf:rfc:3986"/>
    <value value="urn:oid:1.3.6.1.4.1.21367.2005.3.7"/>
</masterIdentifier>

DocumentEntry.URI

The MHD Profile does not directly rely on the DocumentEntry.URI attribute. The related FHIR attribute, DocumentReference.location, is constructed by the MHD Document Responder when building a query response.

DocumentEntry.repositoryUniqueId

This attribute is not relevant to the FHIR environment since FHIR uses a URL to reference document contents from the DocumentReference resource and this URL is automatically generated by the MHD Document Responder. This attribute is not translated into the FHIR environment.

SubmissionSet

SubmissionSet.author attribute

See #DocumentEntry.author_attribute.

SubmissionSet.availabilityStatus attribute

See #DocumentEntry.availabilityStatus_attribute.

SubmissionSet.comments attribute

See #DocumentEntry.comments_attribute.


SubmissionSet.contentTypeCode attribute

This shall be mapped to the type element as follows:

<type>
    <coding>
        <system value="coding scheme value"/>
        <code value="code value"/>
        <display value="display name"/>
    </coding>
</type>

Where system defines the coding scheme the code is taken from. If this is an OID it shall be coded with prefix urn:oid:.

SubmissionSet.entryUUID attribute

See #DocumentEntry.entryUUID_attribute.

SubmissionSet.homeCommunityId attribute

See #DocumentEntry.homeCommunityId_attribute.

SubmissionSet.intendedRecipient attribute

SubmissionSet.intendedRecipient shall be mapped to the Practitioner or Organization resource. The XCN format mapping to a Practitioner resource is shown.

The XCN format used in SubmissionSet

11375^Welby^Marcus^J^Jr. MD^Dr^^^&1.2.840.113619.6.197&ISO

maps to FHIR as

<recipient>
   <reference value="#intendedRecipient"/>
</recipient>

with the DocumentManifest having the contained Practitioner resource

<contained>
   <Practitioner id="intendedRecipient"/>
</contained>

where the translation of the XCN to Practitioner resource is documented in the DocumentEntry.author attribute.

SubmissionSet.patientId attribute

See #DocumentEntry.patientId_attribute.

SubmissionSet.sourceId attribute

The SubmissionSet.sourceId attribute shall be coded as the DocumentManifest.source element.

<source value="urn:oid:1.2.3454.3"/>

The value shall be coded using the urn:oid: prefix.

SubmissionSet.submissionTime attribute

The SubmissionSet.submissionTime attribute shall be coded in FHIR as the created element.

<created value="2005-12-24T09:35:00"/>

SubmissionSet.title attribute

See #DocumentEntry.title_attribute.

SubmissionSet.uniqueId attribute

SubmissionSet.uniqueId is mapped into the FHIR element DocumentReference.masterIdentifier. The following minimal coding shall be provided:

<masterIdentifier>
    <system value="urn:ietf:rfc:3986"/>
    <value value="urn:oid:1.3.6.1.4.1.21367.2005.3.8"/>
</masterIdentifier>

Resource attribute mapping

This is the mapping from FHIR attributes to DocumentEntry attributes.

DocumentManifest

DocumentManifest attribute SubmissionSet attribute
masterIdentifier uniqueId
subject

with reference to contained Patient

patientId
recipient

with reference to contained Practitioner

intendedRecipient type unused - does not semantically

map to contentTypeCode (document vs activity)

Associations

Semantic Mapping

EbRIM Associations are bidirectional pointers. In FHIR a reference between resources is a unidirectional pointer.

SubmissionSet to DocumentEntry HasMember

The SubmissionSet to DocumentEntry HasMember (Original/inclusion by value) association shall be coded in FHIR as a reference embedded in the DocumentManifest.

<content>
    <reference value="#Document1"/>
</content>

Where another entry in the ATOM Feed contains

<DocumentReference id="#Document1">
...
</DocumentReference>

The SubmissionSet to DocumentEntry HasMember (Reference/inclusion by reference) cannot be coded in FHIR. There are two issues. First, the act of submitting a new Document Sharing Association to add linkage between SubmissionSet to DocumentEntry would translate to an update to the DocumentManifest which is currently undefined in MHD. Second, there is no facility in the FHIR DocumentManifest to label a reference as Original vs. Reference.

Life Cycle Associations

The translation of the life cycle associations replace, transforms, signs, appends is specified in this section. In each case a new DocumentReference submission can contain a reference to another DocumentReference already present in the MHD server. In Document Sharing the new DocumentEntry and the life cycle Association are coded together in the submission. In MHD the DocumentReference is coded with the reference to the existing DocumentReference coded internally.

The RPLC Association links together the replacement DocumentEntry in the submission and the original DocumentEntry already present in the Document Registry. As with XDS the entryUUID of the original DocumentEntry must be obtained through query or other means.

As an example in XDS the replace life cycle submission is coded as:

<ExtrinsicObject id="replacementDoc">
...
</ExtrinsicObject>

<Association id="a1"
        sourceObject="replacementDoc"
        targetObject="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873a45"
        associationType="urn:ihe:iti:2007:AssociationType:RPLC"/>

In MHD the replacement DocumentReference is coded as:

<DocumentReference>
...

    <relatesTo>
        <code value="replaces"/>
        <target>
            <reference value="DocumentReference/a54d6aa5-d40d-43f9-88c5-b4633d873a45"/>
        </target>
    </relatesTo>
</DocumentReference>

The relatesTo element is nested inside the DocumentReference resource.

SubmissionSet to Folder HasMember

TBD

SubmissionSet to Folder HasMember HasMember

TBD

Contained FHIR Resources

In order to build up the message context expected in an XDS transaction several FHIR resources must be packaged with either the DocumentReference or DocumentManifest resources as contained resources. The minimal coding for these resource is documented in this section.

Patient - DocumentReference

<Patient>
<!-- DocumentEntry.patientId (required) -->
  <identifier>
    <value value=“1234”/>
    <system value=“urn:oid:1.3.6.1.4.1.21367.2005.3.7”/>
  </identifier>

  <!-- DocumentEntry.sourcePatientInfo (optional) -->
  <!-- patientName -->
  <name>
    <text value="Jonathon K. Doe"/>
    <family value="Doe"/>
    <given value="Jonathon"/>
  </name>
  <gender 
</Patient>

Appendix - mapping exceptions

Time

EbRIM binding used HL7 V2 Date Time format with at most second resolution. FHIR uses xsd:dateTime format which requires second resolution. When translating from XDS to MHD, date/time elements not present in shall be coded as the first value (month 1, day 1, hour 00, minute 00, second 00).