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:
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
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.
- 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
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
- 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)
- Patient ID
- Object construction
- RegistryPackage (SubmissionSet, Folder)
- ExtrinsicObject (DocumentEntry)
- 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.
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
- - Push of XD* metadata and documents over Web Services
- - Push of XD* metadata via email or media (e.g. CD/R)
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.
There are 4 major objects: SubmissionSet, DocumentEntry, Folder, Association, and ObjectRef.
- A submission shall contain a single SubmissionSet object. It anchors the submission and documents the parameters of the submission (time of submission, author, etc.).
- A DocumentEntry object represents a real document (CDA, PDF, etc.) in the submission. It must be a member of the SubmissionSet.
- 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.
- 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.
- 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.
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:
- 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:
- shall have same value as id attribute
The following attributes shall be ignored if present in a submission:
- 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:
- always a globally unique UUID assigned to this object. See Identifiers for discussion.
- always this fixed value
- always this fixed value
- lid (logicalId)
- always same as id on a SubmissionSet
- 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.
- value defined by XD* indicating this RegistryPackage shall be interpreted as a SubmissionSet
The following attributes may be returned from a query:
- required in Cross Community query returns
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
Patient ID consistency across Associations
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.
- Add DocumentEntry object
- Add HasMember Association
- sourceObject references SubmissionSet object
- targetObject references DocumentEntry object
- Association includes SubmissionSetStatus Slot with single value of Original
- 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)
Why do both id and uniqueId exist?
ebRIM identifier, used to link ebRIM objects to build metadata model
symbolic form (submission only), UUID form (submission, storage, and query response)
health care identifier
carried by ss, de, fol objects
metadata segregated by patientid
- exception in ss/sss=reference
The Association object builds a typed relationship between two RegistryObjects. Its required attributes (submission and query response) are:
- 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).
- One RegistryObject
- The other RegistryObject
- Identity of the object. An association itself can be the source or target of another association.
(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:
- Submit the necessary DocumentEntries using any number of submissions
- 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.
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>