This page is part of the FHIR Specification (v0.06: DSTU 1 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Resource XdsEntry - Content 3.18

Status: XDS resource under consideration by IHE and the FHIR project team. Draft for Comment

An entry in an XDS registry.

The resource name as it appears in a RESTful URL is /xdsentry/

This is part of a collaborative piece of work to evaluate FHIR as a specification for providing RESTful access to XDS registries and repositories (e.g. MHD/mHealth initiatives). Neither HL7 nor IHE is committed to pursuing this path - it is simply being evaluated as a possibility.

Through this work, we have identified two different candidate strategies for specifying the XDS interface - this one, and XdsEntry2. Both approaches offer exactly the same functional interface - which is intended to be "all the useful features from existing XDS registries and repositories". However they differ in the resource granularity used. This approach is less granular. It offers less work, but less flexibility of deployment and integration with wider FHIR usage. The XdsEntry2 approach is more granular, which creates slightly more work for bridge developers (FHIR interfaces to full XDS repositories, or XDS.b interfaces to full FHIR repositories), but offers more deployment flexibility and wider FHIR integration after that.

We will be evaluating both approaches during the connectathon cycle through winter 12/13, but will also be happy to accept ballot comments on any of this content and the choice between the two approaches. Note that we have not yet determined a balloting strategy for this work which is partially shared with IHE.

Things to note about both approaches, as compared to the current MHD draft:

Resource Content 3.18.1

UML Image

<XdsEntry xmlns="http://hl7.org/fhir">
 <url><!-- 0..1 uri Direct URL to retrieve the actual document --></url>
 <repositoryId><!-- 0..1 uri repository - logical or literal url --></repositoryId>
 <mimeType><!-- 1..1 string mime type of document --></mimeType>
 <format><!-- 1..1 Coding format (urn:.. Following rules) --></format>
 <class><!-- 1..1 Coding particular kind of document --></class>
 <type><!-- 1..1 Coding precise kind of document --></type>
 <title><!-- 0..1 string title of the document --></title>
 <documentId><!-- 1..1 uri document id - logical or literal url --></documentId>
 <availability><!-- 1..1 code Approved | Deprecated --></availability>
 <confidentialityCode><!-- 1..1 Coding as defined by Affinty Domain --></confidentialityCode>
 <created><!-- 1..1 instant time author created document --></created>
 <event><!-- 0..* Coding main clinical act(s) --></event>
 <hash><!-- 0..1 string hexBinary representation of SHA1 --></hash>
 <size><!-- 0..1 string size in bytes --></size>
 <language><!-- 0..1 string human language (RFC 3066) --></language>
 <folder><!-- 0..* Resource(XdsFolder) folders this document is in --></folder>
 <patientId><!-- 1..1 Identifier subject of care of the document --></patientId>
 <sourcePatientId><!-- 0..1 Identifier subject of care in the document --></sourcePatientId>
 <patientInfo><!-- 0..1 Resource(Person) demographic details --></patientInfo>
 <author>  <!-- 1..* human/machine that authored document -->
  <name><!-- 0..1 HumanName name of human/machine --></name>
  <id><!-- 0..1 Identifier id of human/machine --></id>
  <role><!-- 0..* string role of author wrt to the patient --></role>
  <specialty><!-- 0..* string speciality of facility per affinity domain --></specialty>
  <institution>  <!-- 0..* facilty under which document authored -->
   <id><!-- 0..1 Identifier id of facility --></id>
   <name><!-- 0..1 string name of facility --></name>
  </institution>
  <contact><!-- 0..* Contact contact details for author --></contact>
 </author>
 <authenticator>  <!-- 0..1 legal authenticator/attestor -->
  <id><!-- 0..1 Identifier id of authenticator --></id>
  <name><!-- 0..1 HumanName name of authenticator --></name>
 </authenticator>
 <facilityType><!-- 0..1 Coding type of organizational setting --></facilityType>
 <practiceSetting><!-- 1..1 Coding clinical speciality of the act --></practiceSetting>
 <homeCommunity><!-- 0..1 uri globally unique community id --></homeCommunity>
 <service>  <!-- 1..1 when service being document happened -->
  <start><!-- 1..1 dateTime Start time --></start>
  <stop><!-- 0..1 dateTime Stop time --></stop>
 </service>
 <comments><!-- 0..1 string comments as specified by affinity domain --></comments>
 <extension><!-- 0..* Extension  See Extensions  --></extension>
 <text><!-- 1..1 Narrative Text summary of resource (for human interpretation) --></text>
</XdsEntry>

Alternate definitions: Schema/Schematron, RDF (to do), XML, XMI (to do), Resource Profile

Terminology Bindings

PathDetailsStrength
XdsEntry.availability The availability status of document (see http://hl7.org/fhir/xds-entry-availability for values)complete/required

Constraints

Entries and Folders 3.18.1.1

In XDS, each patient has a series of documents. The documents are each entered in the registry as an XdsEntry that describes the document and its metadata (format/type/etc + patient/author/etc) and references the actual source of the document by a URL at which it may be retrieved.

In addition, documents may be placed into folders that serve to support additional workflow associated with documents. A document may be placed into multiple folders or none at all. Each entry identifies the folders with which it is associated by listing the folder references in the XdsEntry resource. There is a separate resource XdsFolder, which details the folders that have been created for a specific patient.

Note that there is no system wide list of folders, nor do folders need to be predefined before they are used, though servers may choose to impose additional rules concerning which folders may be used.

A client may retrieve the list of folders associated with a patient by searching the folders with a patientId parameter, and a list of documents in a folder by searching the documents with a folderId parameter.

To place an entry in a folder, a client should first ensure that a folder exists with the appropriate codes, and/or determine its identity, and then create/update the XdsEntry resource so that the folder reference is listed in the XdsEntry.folder list.

Search Parameters 3.18.2

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.

$page : integerStarting offset of the first record to return in the search setsingle
$count : integerNumber of return records requested. The server is not bound to conformsingle
$id : tokenThe logical resource id associated with the resource (must be supported by all servers)single
repositoryId : stringrepository - logical or literal urlunion
mimeType : stringmime type of documentunion
format : qtokenformat (urn:.. Following rules)union
class : qtokenparticular kind of documentunion
type : qtokenprecise kind of documentunion
documentId : stringdocument id - logical or literal urlunion
availability : stringApproved | Deprecatedunion
confidentialityCode : qtokenas defined by Affinty Domainunion
created : datedate equal to time author created documentsingle
created-before : datedate before or equal to time author created documentsingle
created-after : datedate after or equal to time author created documentsingle
event : qtokenmain clinical act(s)union
language : stringhuman language (RFC 3066)union
folderId : qtokenfolders this document is inunion
patientId : qtokensubject of care of the documentunion
patientInfo : qtokendemographic detailsunion
authorName : stringname of human/machineunion
authorId : qtokenid of human/machineunion
facilityType : qtokentype of organizational settingunion
practiceSetting : qtokenclinical speciality of the actunion
homeCommunity : stringglobally unique community idunion
serviceStart : datedate equal to Start timesingle
serviceStart-before : datedate before or equal to Start timesingle
serviceStart-after : datedate after or equal to Start timesingle
serviceStop : datedate equal to Stop timesingle
serviceStop-before : datedate before or equal to Stop timesingle
serviceStop-after : datedate after or equal to Stop timesingle
comments : stringcomments as specified by affinity domainunion

(See Searching).


This is an old version of FHIR retained for archive purposes. Do not use for anything else
Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.
© HL7.org 2011 - 2012. FHIR v0.06 generated on Tue, Dec 4, 2012 00:04+1100. License