XDStar Documentation

XD Star Re-documentation Effort

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

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

List all profiles and transactions to which this information model applies.

Submissions and queries

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

(Should Retrieve be included in this section?)

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. Queries carry metadata only in the response message. Submissions shall conform to the rules of metadata composition. Queries may return any combination of metadata objects.

Metadata objects

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

SubmissionSet object

A submission contains a 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.). For a DocumentEntry to be part of a submission it must be a member of a SubmissionSet.

Folder object

A Folder is a grouping of DocumentEntries, like a directory on a PC. To be submitted to an XDS Document Registry, it must be a member of a 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.

ObjectRef object

Description

XML representation of the major objects

Each of the major objects has an XML representation controlled by the ebRIM 3.0 specification. 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 (ProvideAndRegister Document Set or Register Document Set transactions) 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 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. 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" home=""
    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 a discussion of the identifiers used in XD* and why the submission value and query response value is different.

objectType

always this fixed value

status

always this fixed value

lid (logicalId)

always same as id on a SubmissionSet

home

required in Cross Community query returns

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* meaning this RegistryPackage shall be interpreted as a SubmissionSet

Metadata composition rules

The following rules 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 ...

Member of a Folder

Description

Patient ID consistency across Associations

Description

Rule

Description

Rule

Description

The following rules apply to metadata as it resides inside a Document Registry. (this may not be useful since we are documenting interfaces)

Rule

Description

Rule

Description

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.

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

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.