XDS-FHIR-mapping

From IHE Wiki
Revision as of 07:55, 19 May 2014 by BillM (talk | contribs) (→‎HL7/FHIR Mapping Overview)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

These notes contain the current thinking on how to map Document Sharing attributes to FHIR. This page will be updated as we learn more.

In the tables below, the left side is the current ebRIM content and the right side is the proposed FHIR content.

DocumentEntry

DocumentEntry Wrapper

<ExtrinsicObject 

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

XDS 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?).

author

Contained Resources

The FHIR model assumes that, as a general model, resources are pushed to FHIR servers independently. Then when they are needed they are referenced by their URL.

So, in the FHIR model an author and its properties would be stored first and then DocumentReferences would be linked to the author(s). XDS disagrees with this model and instead submits the author information with the DocumentEntry. The way to accommidate this in FHIR is to include the author information in the DocumentReference in the contained section. Contained means resources that would normally be linked but instead are supplied in the submission. 

<rim:Classification classificationScheme="urn:uuid:93606bcf-9494-
43ec-9b4e-a7748d1a838d" classifiedObject="theDocument"
id=”ID_045”
objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="">
<!-- nodeRepresentation intentionally left blank -->
<rim:Slot name="authorPerson">
<!-- shall be single valued, includes
optional ID -->
               <rim:ValueList>
<rim:Value>D12398^Doe^John^^^^^^&1.2.3.4.5.6.7.8. 9.1789.45.1&ISO</rim:Value>
               </rim:ValueList>
        </rim:Slot>
<rim:Slot name="authorInstitution"> <!-- may be multivalued -->
               <rim:ValueList>
                      <rim:Value> Some
Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45</rim:Value> </rim:ValueList>
</rim:Slot>
<rim:Slot name="authorRole">
<!-- may be multivalued -->
               <rim:ValueList>
                      <rim:Value>name of
role</rim:Value>
               </rim:ValueList>
</rim:Slot>
<rim:Slot name="authorSpecialty"> <!-- may be multivalued -->
               <rim:ValueList>
                       <rim:Value>specialty of
author</rim:Value>
               </rim:ValueList>
</rim:Slot>
<rim:Slot name="authorTelecommunication">
               <!-- shall be single valued -->
<rim:ValueList> <rim:Value>^^Internet^john.doe@healthcare.example
.org</rim:Value>
               </rim:ValueList>
        </rim:Slot>
</rim:Classification>

  <contained>
    <Practitioner id="a1">
      <name>
        <family value="Dopplemeyer"/>
        <given value="Sherry"/>
      </name>
      <telecom>
        <system value="email"/>
        <value value="john.doe@healthcare.example.org"/>
      </telecom>
      <organization>
        <display value="Cleveland Clinic"/>
      </organization>
      <role>
        <text value="Primary Surgon"/>
      </role>
      <specialty>
        <text value="Orthopedic"/>
      </specialty>
    </Practitioner>
  </contained>
  <contained>
    <Practitioner id="a2">
      <name>
        <family value="Smitty"/>
        <given value="Gerald"/>
      </name>
      <telecom>
        <system value="email"/>
        <value value="john.doe@healthcare.example.org"/>
      </telecom>
      <organization>
        <display value="Cleveland Clinic"/>
      </organization>
      <role>
        <text value="Attending"/>
      </role>
      <specialty>
        <text value="Orthopedic"/>
      </specialty>
    </Practitioner>
  </contained>

  <author>
    <reference value="#a1"/>
  </author>
  <author>
    <reference value="#a2"/>
  </author>

The contained elements go after the text element and before the masterIdentifier. These are formed as contained elements because this content would normally already be in a FHIR repository and simply referenced by this DocumentReference resource. Note that these items are referenced by the id attribute on the Practitioner elements.

Author is R2 in XDS but in FHIR it is 1..*. This is a problem.

Author sub-attribute issues

XDS Requirements FHIR
Can code authorPerson, authorTelecom, authorInstitution, authorRole, authorSpeciality All of these sub-attributes present
At a minimum, one of these is required: authorPerson, authorTelecom, authorInstitution

availabilityStatus

   <ExtrinsicObject id="Document01" mimeType="text/plain"
       objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
       status="urn:oasis:names:tc:ebxml-regrep:StatusType:Success">

   <status value=”current”/>

In ebRIM the values are Approved and Deprecated. In FHIR the values are current and superceded and entered in error. Superceded corresponds to Deprecated.

availabilityStatus is optional on submission but FHIR status is strictly 1..1.

In FHIR there is a separate attribute docStatus. This does not look useful to XDS.

classCode

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

  <class>
    <coding>
      <system value="http://ihe.net/xds/connectathon/localClassCodes"/>
      <code value="History and Physical"/>
      <display value="History and Physical"/>
    </coding>
  </class>

As is typical in FHIR, the code system is identified as a dereference-able URI and not an OID. The cardinalities align (R vs 1..1).

See also typeCode.

confidentialityCode

<rim:Classification
       classificationScheme=
"urn:uuid:f4f85eac-e6cb-4883-b524-
f2705394840f" classifiedObject="theDocument"
id=”ID_047”
objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="confidentialityCode" >
       <rim:Name>
               <rim:LocalizedString
value="displayName"/>
       </rim:Name>
<rim:Slot name="codingScheme"> <rim:ValueList>
<rim:Value>XDS Affinity Domain Specific Value</rim:Value>
               </rim:ValueList>
        </rim:Slot>
</rim:Classification>

  <confidentiality>
    <coding>
      <system value="http://ihe.net/xds/connectathon/confidentialityCodes"/>
      <code value="1.3.6.1.4.1.21367.2006.7.101"/>
      <display value="Clinical-Staff"/>
    </coding>
  </confidentiality>

It is odd to see confidentiality as an element of DocumentReference resource. In class they pointed to confidentiality as something that would potentially change often so it should be stored outside the main resource. This would allow the resource to be signed and then updates to confidentiality would not require re-signing of the resource.

As is typical in FHIR, the code system is identified as a dereference-able URI and not an OID.

creationTime

<Slot name="creationTime">
   <ValueList>
     <Value>20051224</Value>
   </ValueList>
 </Slot>

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

FHIR has separate created and indexed elements. They correspond to the creationTime at or in front of the Document Source and the time they were stored in the Registry. We currently have no use for indexed.

entryUUID

There is no concept in FHIR corresponding to entryUUD. In XDS.b we have uniqueId which is the primary externally used healthcare id and entryUUID which is forced upon us by the structure of the ebRIM message.

In the construction of a FHIR transaction, UUID format identifiers are use to link parts of the transaction together. These identifiers correspond to the SOAP Content IDs which are typically built from the values in entryUUID. This identifiers in FHIR are valid only within the context of the transaction in much the same way that symbolic values for entryUUID are.

These administrative IDs used in FHIR transactions need further investigation.

formatCode

<Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
    classifiedObject="Document01" nodeRepresentation="urn:ihe:iti:bppc:2007"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_5">
    <Slot name="codingScheme">
        <ValueList>
            <Value>1.3.6.1.4.1.19376.1.2.3</Value>
        </ValueList>
    </Slot>
    <Name>
        <LocalizedString value="urn:ihe:iti:bppc:2007"/>
    </Name>
</Classification>

  <format>
    <coding>
      <system value="http://ihe.net/xds/formatCodes"/>
      <code value="urn:oid:1.3.6.1.4.1.21367.2006.7.101"/>
      <display value="urn:ihe:iti:bppc:2007"/>
    </coding>
  </format>

As is typical in FHIR, the code system is identified as a dereference-able URI and not an OID. Cardinality works (R vs 0..*). FHIR reference

hash

<Slot name="hash">
    <ValueList>
        <Value>e543712c0e10501972de13a5bfcbe826c49feb75</Value>
    </ValueList>
</Slot>

<hash value="e543712c0e10501972de13a5bfcbe826c49feb75"/>

Cardinality is 0..1 so this works for both Provide and Register and Register transactions.

hash

<Slot name="hash">
    <ValueList>
        <Value>e543712c0e10501972de13a5bfcbe826c49feb75</Value>
    </ValueList>
</Slot>

<hash value="e543712c0e10501972de13a5bfcbe826c49feb75"/>



healthcareFacilityTypeCode, eventCodeList, serviceStartTime, serviceStopTime

<Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
    classifiedObject="Document01" nodeRepresentation="Outpatient"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_6">
    <Slot name="codingScheme">
        <ValueList>
            <Value>Connect-a-thon healthcareFacilityTypeCodes</Value>
        </ValueList>
    </Slot>
    <Name>
        <LocalizedString value="Outpatient"/>
    </Name>
</Classification>
<Classification classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
    classifiedObject="theDocument" id="ID_048"
    objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification"
    nodeRepresentation="eventCode">
    <Name>
        <LocalizedString value="eventCodeDisplayName"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>XDS Affinity Domain Specific Value</Value>
        </ValueList>
    </Slot>
</Classification>
<Slot name="serviceStartTime">
    <ValueList>
        <Value>200412230800</Value>
    </ValueList>
</Slot>
<Slot name="serviceStopTime">
    <ValueList>
        <Value>200412230801</Value>
    </ValueList>
</Slot>

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

There are no issues with cardinality.

languageCode

<Slot name="languageCode">
  <ValueList>
    <Value>en-US</Value>
  </ValueList>
</Slot>
 
<primaryLanguage value="en-US"/>

legalAuthenticator




<authenticator>  <!-- 0..1 -->
   [content missing here]
</authenticator>





mimeType






    mimeType="text/plain"




   <mimeType value="text/plain"/>





patientId, sourcePatientId, sourcePatientInfo


Coding patient information in a FHIR DocumentReference resource is foreign to the approach FHIR takes.  A patient would already be defined by a resource in a FHIR service.  A DocumentReference would not include patient information but instead link to the patient resource. That is why in this example the patient information is wrapped in a contained element. This indicates that although this information is somewhat foreign to this resource it is include for some special reason. Then the patient element inside the DocumentReference resource links to this contained patient element.







<ExternalIdentifier
   identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
   value="76cc765a442f410^^^&1.3.6.1.4.1.21367.2005.3.7&ISO"
   objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
   id="id_9" registryObject="Document01">
   <Name>
     <LocalizedString value="XDSDocumentEntry.patientId"/>
   </Name>
 </ExternalIdentifier>
<Slot name="sourcePatientId">
  <ValueList>
    <Value>89765a87b^^^&3.4.5&ISO</Value>
  </ValueList>
</Slot>
<Slot name="sourcePatientInfo"> 
  <ValueList>
    <Value>PID-3|DTP-1^^^&1.3.6.1.4.1.21367.2005.3.7 &ISO</Value>
    <Value>PID-5|Chalmers^Peter^^^</Value>
    <Value>PID-7|19650120</Value> 
    <Value>PID-8|M</Value> 
    <Value>PID-11|100 Main St^^Burlington^MA^01803^USA</Value> 
  </ValueList>
</Slot>




<contained>
<Patient>
  <identifier>   
    <value value="76cc765a442f410"/>
    <system value="1.3.6.1.4.1.21367.2005.3.7"/>
  </identifier>
  <identifier>  
   <use value="usual"/>
   <value value="89765a87b"/>
   <value system="3.4.5"/>
  </identifier>
  <name>
    <use value="official"/>
    <family value="Chalmers"/>
    <given value="Peter"/>
  </name>
  <birthDate value="1965-01-20"/>
  <gender>
    <coding>
      <system value="http://hl7.org/fhir/v3/AdministrativeGender"/>
      <code value="M"/>
      <display value="Male"/>
    </coding>
  </gender>
  <address>
    <use value="home"/>
    <line value="100 Main St"/>
    <city value="Burlington"/>
    <state value="MA"/>
    <zip value="01803"/>
  </address>
</Patient>
</contained>





Attributes patientId, sourcePatientId, sourcePatientInfo are coded as three separate attributes in ebRIM.  In FHIR they are all part of the Patient structure. Note that in the ebRIM binding 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.






practiceSettingCode













referenceIdList






<Slot name="urn:ihe:iti:xds:2013:referenceIdList ">
    <ValueList>
        <Value> 2013001^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:accession</Value>
        <Value> 1.2.3.12.78.23^^^^urn:ihe:iti:xds:2013:uniqueId^&1.2.3.4&ISO</Value>
    </ValueList>
</Slot>




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





From a FHIR perspective these are other administrative identifiers.  Their type is defined by the identifier system. The special handling comes from the specialized XDS/FHIR server that uses them to satisfy certain queries.  

BTW, queries in FHIR are defined against a particular resource like DocumentReference. We will need to define the equivalent of our stored queries agains the DocumentResource and DocumentManifest resources.






size






<Slot name="size">
    <ValueList>
        <Value>4309</Value>
    </ValueList>
</Slot>




<size value="4309"/>





title






<Name>
  <LocalizedString value="Physical"/>
</Name>




<description value="Physical"/>





typeCode






<Classification
    classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
    classifiedObject="Document01" nodeRepresentation="Outpatient"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
    id="id_6">
    <Slot name="codingScheme">
        <ValueList>
            <Value>Local healthcareFacilityTypeCodes</Value>
        </ValueList>
    </Slot>
    <Name>
        <LocalizedString value="Outpatient"/>
    </Name>
</Classification>




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





Our use of both classCode and typeCode makes no sense to HL7 folks.  Here our typeCode translates to their class object. For now I show both #typeCode and classCode mapping into a class object.  This violates the 0..1 cardinality of the FHIR class object.



uniqueId






<ExternalIdentifier
  identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
  value="1.3.6.1.4.1.21367.2005.3.7"
  objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
  id="id_10" registryObject="Document01">
  <Name>
    <LocalizedString value="XDSDocumentEntry.uniqueId"/>
  </Name>
</ExternalIdentifier>




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





The uniqueId is represented by the masterIdentifier. The big different is that in XDS the value is an OID and in FHIR it is a fully qualified OID.



URI, repositoryUniqueId









<location value="[uri]"/><!--  0..1 -->





A few conflicts here. There is no concept of repositoryUniqueId. In XDS.b the document is retrieved via a SOAP request to the endpoint representing the repositoryUniqueId.  FHIR supports retrieve via HTTP GET where the URIis coded in the above location element. The service element would seem on the surface to be useful here but it is isn’t. It seems easier to have a document retrieve service based on HTTP GET that translates its parameters and MHD actor state into an XDS.b retrieve request on the back end.







Retrieved from "http://wiki.ihe.net/index.php?title=XDS-FHIR-mapping&oldid=77140"