XDStar Documentation

From IHE Wiki
Revision as of 12:43, 15 February 2011 by BillM (talk | contribs) (→‎Member of a SubmissionSet)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

XD Star Re-documentation Effort

(or at least Bill's point of view on same)

The current effort focuses on the Information Model section. Most other sections are parking lots for issues for later.

This page has grown to be multiple pages. The others are:

EbRIM Documentation

XDStar Data Dictionary

Admin

How does this apply to the Technical Framework?

Unknown at this time. The short term goal (as of Feb 1, 2011) is to develop example sections to evaluate how to proceed and integrate with the existing Technical Framework.

Management of support material

This means use of wiki vs ftp.

Ftp is good for downloading WSDL, Schema, one file examples

Wiki is good for annotated examples and long descriptions due to the formatting available.

Need to settle on:

  • When to use one over the other
  • How to reference
  • How to cross link

Future

Need example sections for ConOps and Info Model so style can be compared to Metadata Attribute table redo effort that Karen is undertaking. Will they work together?

Produce report back to full ITI Tech Committee (and beyond) to get greater review of approach. Target date is Summer 2011.

Other topics

  • Informative sections (maybe appendices):
    • ebRS reference (as applied to XD*)
    • ebRIM reference (as applied to XD*)
  • Testing issues
    • Error messages referring to section numbers
  • Educational material (I don't know details on this)
  • Cross profile interactions

ConOps

Concepts of Operation - high level view of XD*. Written at a high enough level that you don't need to be an engineer to understand it. (Darn it Jim, I'm a doctor not an engineer! -- Dr. McCoy of Star Trek).

This is a narrative and includes no reference material.

Target audience: Planning Committee, other committees that wish to profile the use of XD*, users

Content includes:

  • List of all XD* profiles
  • Brief description of their purpose, actors, and transactions
  • High level similarities and differences of these profiles
  • High level metadata contraints of each

Information Model Outline

Part, or all, of this is a documentation of the metadata model for XD* from these perspectives:

  • Major element definitions (SubmissionSet, DocumentEntry, Folder, Association, ObjectRef)
  • Submission (Provide and Register, Register perspectives)
    • Basics (Submission Set)
    • How to incrementally add content to a submission (assembly instructions)
    • Rules for adding content (if you add this my must also add this, may also add this...)
  • Variance for non-XDS profiles (XDR, XDM, XCA)
  • Query and Query response
    • LeafClass vs ObjectRef
    • Short descriptions of all Stored Queries
    • What profiles offer query and how they are different
  • How to interpret query responses
  • ID management
    • id (symbolic, UUID)
    • uniqueid
    • Patient ID
  • Object construction
    • RegistryPackage (SubmissionSet, Folder)
    • ExtrinsicObject (DocumentEntry)
    • Association
    • ObjectRef
  • Attribute construction
    • Slot, title, description, classification (internal, external), externalidentifier

Target audience: developers. This is a normative reference and HowTo guide. It is not transaction oriented. Instead, it discusses the rules for metadata and as appropriate indicates which transaction(s) a rule or concept applies.

Information Model

This information model applies to the XD* profiles which are:

Cross-Enterprise Document Sharing (XDS)
- Sharing of metadata and documents organized by Document Registry and Document Repositories
(XDR)
- Push of XD* metadata and documents over Web Services
(XDM)
- Push of XD* metadata via email or media (e.g. CD/R)
(XCA)
BLAH
BLAH

Submissions and queries

(This section needs a better name and some organization)

(Should Retrieve be included in this section?)

Different rules apply to metadata depending on whether the metadata is part of a submission or a query response type transaction.

Submission type transactions are:

Provide and Register Document Set (XDS)
Provide and Register Document Set (XDR)
Register Document Set (XDS)
xxxx (XDM) (this is a profile not a transaction)

...

Query type transactions are:

Stored Query (XDS)
Cross-Community Query (XCA)

...

Submissions carry metadata only in the request message. They shall conform to the rules of metadata composition. Queries carry metadata only in the response message. They may return any combination of metadata objects.

Metadata holding actors

This is a descriptive label for actors which respond to queries. There are a few metadata rules that apply to this type of actor.

Document Registry
Responding Gateway
This actor represents a community and accepts query transactions. From outside appearances it is a holder of metadata.

Metadata objects

There are 4 major objects: SubmissionSet, DocumentEntry, Folder, Association, and ObjectRef.

SubmissionSet object
A submission shall contain a single SubmissionSet object. It anchors the submission and documents the parameters of the submission (time of submission, author, etc.).
DocumentEntry object
A DocumentEntry object represents a real document (CDA, PDF, etc.) in the submission. It must be a member of the SubmissionSet.
Folder object
A Folder is a grouping of DocumentEntries, like a directory on a PC. To be part of a submission , it shall be a member of the SubmissionSet.
Association object
Associations build relationships or links between SubmissionSet, DocumentEntry, and Folder objects. The most common Association type is HasMember which is used to link SubmissionSets and Folders to their contents/members. Some types of Associations must be a member of the SubmissionSet.
ObjectRef object
A reference to a RegistryObject. Can be returned from a query to indicate the identity of a matching object without including the full metadata.

XML representation of the metadata objects

Each of the major objects has an XML representation controlled by the ebRIM 3.0 specification. The submission form is different from the query response form in that there are attributes which are optional in submission but required in query response. In each discussion below the contents of the object is removed for clarity.

SubmissionSet XML

The SubmissionSet object is based on an ebRIM RegistryPackage object. An example as it is submitted is: 

<rim:RegistryPackage id="SubmissionSet"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">

    <Classification classifiedObject="SubmissionSet"
        classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/>
</rim:RegistryPackage>

The following attributes shall be present in a submission:

id
identity of the object. Can have a symbolic (unique within the submission and no urn:uuid: prefix) or UUID value.

The following attributes may be present in a submission:

lid
shall have same value as id attribute

The following attributes shall be ignored if present in a submission:

status
Status is controlled by the Document Registry actor in XDS and the Document Recipient actor in XDR.

The classification is necessary to label this generic RegistryPackage object as a SubmissionSet. The other use of RegistryPackage in XD* is a Folder. The value of classificationNode is assigned by XD*. Note that in this example the classification is a child of RegistryPackage. It may also be a peer of RegistryPackage. These two forms shall be considered equivalent. A valid SubmissionSet has a collection of required and optional contents which are not shown here.

The same SubmissionSet as returned from a Stored Query transaction is: 

<rim:RegistryPackage id="urn:uuid:e6af9f27-9d63-4e6a-b292-ae502fdacc41"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:RegistryPackage"
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
    lid="urn:uuid:e6af9f27-9d63-4e6a-b292-ae502fdacc41"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">

    <Classification classifiedObject="urn:uuid:e6af9f27-9d63-4e6a-b292-ae502fdacc41"
        classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/>

</rim:RegistryPackage>

The following attributes shall be returned from a query:

id
always a globally unique UUID assigned to this object. See Identifiers for discussion.
objectType
always this fixed value
status
always this fixed value
lid (logicalId)
always same as id on a SubmissionSet
classifiedObject
refers to value of RegistryPackage id attribute. Links Classification to RegistryPackage. This is required whether Classification is code as a peer of the RegistryPackage or as a child of RegistryPackage.
classificationNode
value defined by XD* indicating this RegistryPackage shall be interpreted as a SubmissionSet

The following attributes may be returned from a query:

home
required in Cross Community query returns

DocumentEntry XML

Folder XML

Association XML

ObjectRef XML

Metadata composition rules

The following rules shall apply when composing a metadata submission.

(note: individual rules should include short XML examples as necessary to demonstrate the application of the rule)

Submission includes SubmissionSet
Every submission shall contain one SubmissionSet object.
Member of a SubmissionSet
A metadata object (DocumentEntry, Folder, or Association) is a member of a SubmissionSet if there is a HasMember linking the object with the SubmissionSet object. For DocumentEntry objects, there are two kinds of membership in a SubmissionSet:
  • Original - the DocumentEntry was submitted with the SubmissionSet
  • Reference - the DocumentEntry was added to the SubmissionSet in a separate submission after the submission of the SubmissionSet object. In this case the SubmissionSet object is being used as a grouping of DocumentEntry objects. One motivation for this is that ...

Every DocumentEntry and Folder in a submission shall be a member of the SubmissionSet.

Member of a Folder
Description
Patient ID consistency across Associations
Description
Rule
Description
Rule
Description

Submission Patterns

A submission pattern is a set of instructions for adding a specific pattern of metadata to a submission. A submission always includes a single SubmissionSet object. Each of the patterns below document the metadata to be added to a submission. There is no limit on the amount of content sent in a single SubmissionSet. The DocumentEntry pattern describes how to add a DocumentEntry to a Submission. If there are 5 DocumentEntries to be submitted (same submission) then this pattern would be applied 5 times.

DocumentEntry

  • Add DocumentEntry object
  • Add HasMember Association
    • sourceObject references SubmissionSet object
    • targetObject references DocumentEntry object
    • Association includes SubmissionSetStatus Slot with single value of Original

Empty Folder

  • Add Folder object
  • Add HasMember Association
    • sourceObject references SubmissionSet object
    • targetObject references Folder object

Folder with initial DocumentEntries

Add new DocumentEntry to existing Folder

Add existing DocumentEntry to existing Folder

Interpreting metadata as received or returned through a query

Stored content model

(What is expected of XD* content (metadata and documents) while it is stored?)

Approved DocumentEntry ==> document can be retrieved from repository

Deprecated DocumentEntry ==>

id, uid of RegistryObject never change, are globally unique (uid - wink, wink)

Identifiers

Why do both id and uniqueId exist?

Id

ebRIM identifier, used to link ebRIM objects to build metadata model

symbolic form (submission only), UUID form (submission, storage, and query response)

UniqueId

health care identifier

Patient ID

carried by ss, de, fol objects

metadata segregated by patientid

  • exception in ss/sss=reference

Association Metadata

The Association object builds a typed relationship between two RegistryObjects. Its required attributes (submission and query response) are:

associationType
Identifies the type of the Association. Association type names imply a direction. For example the type HasMember indicates one RegistryObject (targetObject) is a member of the other (sourceObject).
sourceObject
One RegistryObject
targetObject
The other RegistryObject
id
Identity of the object. An association itself can be the source or target of another association.

SubmissionSet HasMember

(This content belongs somewhere else???)

The HasMember association between a SubmissionSet and a DocumentEntry contains a slot SubmissionSetStatus: 

<rim:Slot name="SubmissionSetStatus" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
    <rim:ValueList>
        <rim:Value>Original</rim:Value>
    </rim:ValueList>
</rim:Slot>

The value Original (shown) is used only when submitting a new DocumentEntry as part of this SubmissionSet (submission).

When it is necessary to build a collection of DocumentEntries for different Patient IDs, they may be collected under a SubmissionSet. Their SubmissionSet to DocumentEntry HasMember association shall carry the following Slot.

Note: the above form (Slot value of Original) and this form (Slot value of Reference) are never used together. 

<rim:Slot name="SubmissionSetStatus" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
    <rim:ValueList>
        <rim:Value>Reference</rim:Value>
    </rim:ValueList>
</rim:Slot>

The procedure for building this collection is to:

  1. Submit the necessary DocumentEntries using any number of submissions
  2. Submit a SubmissionSet (in a new submission) along with a collection of HasMember Associatons, each:
    • References the SubmissionSet with the sourceObject attribute
    • References an existing DocumentEntry which may have a different Patient ID than the SubmissionSet
    • Each of these Associations carries the Reference form of the SubmissionSetStatus Slot.

Association documentation

Associations of type XFRM, APND, RPLC, and XFRM_RPLC may include documentation describing the association (type of transformation, reason for replacement, etc.). If included, it shall be specified as a Classification on the Association. An example (in submission form) is:


This is the header of the Association. On some Associations this is the only content. 

<rim:Association id="ThisAssociation" associationType="urn:ihe:iti:2007:AssociationType:XFRM"
    sourceObject="Source" targetObject="Target"
    xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">

This is the contained Classification. Above the Association show an associationType of XFRM (transformation). This classification informs us that the transformation is to French.

This Classification is in the form of a coded term. It contains the code (nodeRepresentation attribute) the coding scheme (codingScheme Slot value), and the code name (Name element). 

    <rim:Classification classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3"
        classifiedObject="ThisAssociation" id="ID_043"
        nodeRepresentation="French">
        <rim:Name>
            <rim:LocalizedString value="Translation into French"/>
        </rim:Name>
        <rim:Slot name="codingScheme">
            <rim:ValueList>
                <rim:Value>PhonyCodingScheme</rim:Value>
            </rim:ValueList>
        </rim:Slot>
    </rim:Classification>

</rim:Association>
Retrieved from "http://wiki.ihe.net/index.php?title=XDStar_Documentation&oldid=48297"