MHD-rev2-vol-3

From IHE Wiki
Jump to navigation Jump to search

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

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. At the moment in MHD I refer to the equivalent in the FHIR binding as DocumentReference. What wording style is going to move forward?

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.

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 to Practitioner (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].

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.

Object Types

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.

DocumentReference

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 (as opposed to hand generated?). 

<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.

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 document 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:

DS 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.

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.

availabilityStatus attribute

availabilityStatus is coded as the FHIR element 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

classCode attribute

classCode is mapped into the FHIR element 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.

confidentialityCode attribute

confidentialityCode is mapped into the FHIR element 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.

creationTime attribute

creationTime attribute is mapped to the FHIR element created.

Example coding is: 

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

Note that this requires dateTime XML coding.

entryUUID

There is no concept in FHIR corresponding to entryUUD. This is an artifact of the ebRIM binding.

formatCode attribute

formatCode is mapped into the FHIR element format. 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.

hash attribute

hash is mapped into the FHIR element hash. The following minimal coding shall be provided: 

<hash value="e543712c0e10501972de13a5bfcbe826c49feb75"/>

healthcareFacilityTypeCode, eventCodeList, serviceStartTime, serviceStopTime attributes

  <context>
    <event>
      <coding>
        <system value="http://ihe.net/xds/connectathon/eventCodes"/>
        <code value="T-D8200"/>
        <display value="Arm"/>
      </coding>
    </event>
    <period>
      <start value="2004-12-23T08:00:00"/>
      <end value="2004-12-23T08:01:00"/>
    </period>
    <facilityType>
      <coding>
        <system value="http://www.ihe.net/xds/connectathon/healthcareFacilityTypeCodes"/>
        <code value="Outpatient"/>
        <display value="Outpatient"/>
      </coding>
    </facilityType>
  </context>

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.
  • The format for date/time is dateTime XML coding.

.

Retrieved from "http://wiki.ihe.net/index.php?title=MHD-rev2-vol-3&oldid=77419"