Annotated ProvideAndRegister.b Transaction
Annotated Provide and Register transaction.b
What follows is the metadata for a submission of a single document as generated by a Document Source. All the XML shown, when combined, makes a valid submission. This example was generated with the testing tool xdstest using testkit test 11966. A copy of this metadata, without annotations, can be found here.
The Provide and Register.b transaction is always carried in a SOAP over HTTP package formatted with MTOM/XOP rules. An example showing the SOAP and HTTP is found here.
The outer-most wrapper is ProvideAndRegisterDocumentSetRequest. The inner wrapper, RegistryObjectList, contains the actual metadata.
<xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007">
<lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
<rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
Submission Set
All submissions must include a Submission Set object. This documents the act of submission for later investigation. The Submission Set object is constructed from a ebRIM RegistryPackage object with a Classification labeling the RegistryPackage as a Submission Set. The ebRIM RegistryPackage is also used to construct the XDS Folder object so the Classification is important. (The classification is down below, it will be discussed further there.)
The RegistryPackage object must have id and objectType attributes. objectType has a fixed value as shown below. id has either a symbolic value, as show below, or a UUID value. UUID values have the 9 character prefix urn:uuid:. Symbolic values do not. By the time an object is stored in the Registry, it will have a UUID id value. The Registry has the responsibility of assigning UUIDs to all objects that have symbolic ids before storing.
Why use a symbolic id or a UUID? If you want to know what UUID id value is assigned to your objects then you must assign the UUIDs yourself. The Provide and Register transaction does not return to you the values assigned. Why care? If you want to perform a document replace later without performing a query to discover the UUID id value of your object then you must assign UUIDs. Most folks let the Registry perform this task.
<rim:RegistryPackage id="SubmissionSet01"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:RegistryPackage">
Next is the list of attributes of the Submission Set. In ebRIM terms there are three types of attributes:
- Slot
- Name
- Description
- Classification
- ExternalIdentifier
and they must be coded in this order. The schema requires it.
The Submission Set has a single Slot-code attribute: submissionTime which is required.
Many attributes, like submissionTime, have values that are formatted in specific/required ways. Volume 3 of the Technical Framework table 4.1-6 documents the details of this coding. It will not be repeated here.
<rim:Slot name="submissionTime">
<rim:ValueList>
<rim:Value>20041225235050</rim:Value>
</rim:ValueList>
</rim:Slot>
Next come the optional title and comments attributes coded as ebRIM Name and Description.
<rim:Name>
<rim:LocalizedString value="Physical"/>
</rim:Name>
<rim:Description>
<rim:LocalizedString value="Annual physical"/>
</rim:Description>
Next are the Classifications. There is no ordering to the classifications so they will be discussed in the order of this submission. First is an Author attribute which is coded as an ebRIM Classification object with significant internal structure. There may be multiple authors coded, each is coded as a separate Classification with no significance given to order. Other kinds of classifications will be discussed below.
The author attribute is labeled R2, required if known. The classification object is a wrapper for a collection of attributes describing an author. The XML attributes of the Classification element are decoded as:
- classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d" formally labels the classification as a Submission Set author.
- classifiedObject="SubmissionSet01" indicates which object this Classification is part of (technically this is redundant since this Classification is nested inside its owner but the schema requires this attribute)
- objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" another redundant but required label
- nodeRepresentation="" a scheme required Classification attribute that is not used and must be the empty string
- id="id_11" all Classification elements must have a unique id (if symbolic must be unique within the submission, if UUID must be globally unique)
<rim:Classification
classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d"
classifiedObject="SubmissionSet01" nodeRepresentation=""
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
id="id_11">
An author has a collection of sub-attributes which are ebRIM coded as Slots within the Classification. The authorPerson Slot is required and has a single value describing this author.
<rim:Slot name="authorPerson">
<rim:ValueList>
<rim:Value>^Dopplemeyer^Sherry^^^</rim:Value>
</rim:ValueList>
</rim:Slot>
Optionally, an authorInstitution can be included.
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>Cleveland Clinic</rim:Value>
<rim:Value>Berea Community</rim:Value>
</rim:ValueList>
</rim:Slot>
Optionally, roles can be document regarding the author
<rim:Slot name="authorRole">
<rim:ValueList>
<rim:Value>Primary Surgon</rim:Value>
</rim:ValueList>
</rim:Slot>
Optionally, specialties can be coded.
<rim:Slot name="authorSpecialty">
<rim:ValueList>
<rim:Value>Orthopedic</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
The next classification is the ebRIM coding of the Content Type Code attribute which is required and can only have a single value (single Classification object of this type). The XML attributes of the Classification element are decoded as:
- classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" formally labels the classification as a Submission Set Content Type Code.
- classifiedObject="SubmissionSet01" indicates which object this Classification is part of (technically this is redundant since this Classification is nested inside its owner but the schema requires this attribute)
- objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" another redundant but required label
- nodeRepresentation="" a scheme required Classification attribute that is not used and must be the empty string
- id="id_12" all Classification elements must have a unique id (if symbolic must be unique within the submission, if UUID must be globally unique)
The remaining structure is the same for all Coded Attributes. A Coded Attribute has three parts: code value, coding scheme (from which the code value is taken), and code display name. Coded values used in metadata are controlled by the configuration of the Affinity Domain. The Affinity Domain configuration for the Public Registry is documented here. Submission of a coded attribute is validated against the Affinity Domain configuration. The display name is not validated since it will vary by local language and custom.
The three parts of a coded attribute are encoded in ebRIM as:
- code value - nodeRepresentation attribute
- coding scheme - codingScheme slot (must be single value)
- display name - Name attribute
<rim:Classification
classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="SubmissionSet01" nodeRepresentation="History and Physical"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
id="id_12">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon contentTypeCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="History and Physical"/>
</rim:Name>
</rim:Classification>
A submission set requires 3 identifiers: uniqueID, PatientID, and sourceID which are encoded as ebRIM ExternalIdentifier attributes. The required structure of the ExternalIdentifier is:
- identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" labels the first ExternalIdentifier as a Submission Set UniqueID (note the other two have their own values)
- objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" - ebRIM required decoration
- registryObject="SubmissionSet01" - redundantly documents what major object this attribute belong to
- id="id_13" - like a Classification, an ExternalIdentifier has identity and requires an id attribute
- the Name structure is required as shown
The value of the UniqueID/PatientID/SourceID is coded as the value attribute. The UniqueID must be a globally unique OID. If the Registry detects a UnqiueID collision the submission will be rejected. The Submission Set is identified by two unique id attributes: the XML id attribute of the RegistryPackage that defines the Submission Set and the UniqueID. In some ways this is redundant but necessary in other ways.
The SourceID documents which Document Source made the submission.
The PatientID is, well, the patient id. Notice there is a lot of structure here. The part between the two & (note XML encoding of & is &) is the OID identifying the patient id assigning authority. There is exactly one of these for an Affinity Domain. The part before the ^^^ is the identifier for this patient within this assigning authority.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8"
value="1.2009.0827.08.33.5017"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
id="id_13" registryObject="SubmissionSet01">
<rim:Name>
<rim:LocalizedString value="XDSSubmissionSet.uniqueId"/>
</rim:Name>
</rim:ExternalIdentifier>
<rim:ExternalIdentifier
identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832"
value="1.3.6.1.4.1.21367.2009.1.2.1"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
id="id_14" registryObject="SubmissionSet01">
<rim:Name>
<rim:LocalizedString value="XDSSubmissionSet.sourceId"/>
</rim:Name>
</rim:ExternalIdentifier>
<rim:ExternalIdentifier
identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446"
value="ef77eeda67dd4a2^^^&1.3.6.1.4.1.21367.2005.3.7&ISO"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
id="id_15" registryObject="SubmissionSet01">
<rim:Name>
<rim:LocalizedString value="XDSSubmissionSet.patientId"/>
</rim:Name>
</rim:ExternalIdentifier>
</rim:RegistryPackage>
Document Entry
Next is the Document Entry object which is constructed from an ebRIM ExtrinsicObject object. In a Provide and Register transaction there is a one-to-one relationship between Document Entry objects and actual documents attached through the MTOM/XOP encoding. The id attribute is used to connect the ExtrinsicObject to the Mime Part.
The XML attributes of the ExtrinsicObject element are:
- id - all ExtrinsicObject elements must have a unique id (if symbolic must be unique within the submission, if UUID must be globally unique)
- mimeType - documents the mime type of the document being submitted
- objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" - ExtrinsicObjects are extendable (can create sub-types). This is controlled by the objectType value. A Document Entry is an ebRIM ExtrinsicObject with this objectType value. IHE may use the ebRIM ExtrinsicObject to define other objects in the future so it is important to have/maintain this value.
<rim:ExtrinsicObject id="Document01" mimeType="text/plain"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">
Next is the list of attributes of the Document Entry. In ebRIM terms there are three types of attributes: Slot Name Description Classification ExternalIdentifier and they must be coded in this order. The schema requires it.
A Document Entry object holds the following required/optional attributes based on the ebRIM Slot:
Required
- creationTime
- languageCode
- sourcePatientId
Optional
- legalAuthenticator
- serviceStartTime (technically R2 - required if known)
- serviceStopTime (technically R2 - required if known)
- sourcePatientInfo
These attributes can be included and if they are they must match the contents (Repository can verify and reject if not correct)
- hash
- size
<rim:Slot name="creationTime">
<rim:ValueList>
<rim:Value>20051224</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="languageCode">
<rim:ValueList>
<rim:Value>en-us</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="serviceStartTime">
<rim:ValueList>
<rim:Value>200412230800</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="serviceStopTime">
<rim:ValueList>
<rim:Value>200412230801</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="sourcePatientId">
<rim:ValueList>
<rim:Value>89765a87b^^^&3.4.5&ISO</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="sourcePatientInfo">
<rim:ValueList>
<rim:Value>PID-3|89765a87b^^^&3.4.5&ISO</rim:Value>
<rim:Value>PID-5|Doe^John^^^</rim:Value>
<rim:Value>PID-7|19560527</rim:Value>
<rim:Value>PID-8|M</rim:Value>
<rim:Value>PID-11|100 Main St^^Metropolis^Il^44130^USA</rim:Value>
</rim:ValueList>
</rim:Slot>
Next come the optional title and comments attributes coded as ebRIM Name and Description.
<rim:Name>
<rim:LocalizedString value="Physical"/>
</rim:Name>
<rim:Description/>
A Document Entry has a documented author(s) just like the Submission Set. The coding of this attribute is identical to the Submission Set version except for the value of the classificationScheme attribute. Note that this Document Entry has two authors.
<rim:Classification
classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="Document01" nodeRepresentation=""
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
id="id_1">
<rim:Slot name="authorPerson">
<rim:ValueList>
<rim:Value>^Smitty^Gerald^^^</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>Cleveland Clinic</rim:Value>
<rim:Value>Parma Community</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorRole">
<rim:ValueList>
<rim:Value>Attending</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorSpecialty">
<rim:ValueList>
<rim:Value>Orthopedic</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
<rim:Classification
classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="Document01" nodeRepresentation=""
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
id="id_2">
<rim:Slot name="authorPerson">
<rim:ValueList>
<rim:Value>^Dopplemeyer^Sherry^^^</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>Cleveland Clinic</rim:Value>
<rim:Value>Berea Community</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorRole">
<rim:ValueList>
<rim:Value>Primary Surgon</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="authorSpecialty">
<rim:ValueList>
<rim:Value>Orthopedic</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
A Document Entry carries the following code style attributes:
Required
- Class Code (single)
- Confidentiality Code (single)
- Format Code (single)
- Healthcare Facility Type Code (single)
- Practice Setting Code (single)
- Type Code (single)
Optional
- Event Code List (multiple)
The structure of code style attribute is discussed above in the section on Submission Set.
Each of these attributes is assigned a unique UUID as its classificationScheme. The value urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a indicates the Classification is documenting a Class Code. These values are documented in the Technical Framework in Volume 3 Section 4.3.1. As a convenience, they are also available on the web here.
<rim: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">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon classCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="History and Physical"/>
</rim:Name>
</rim:Classification>
<rim:Classification
classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="Document01" nodeRepresentation="1.3.6.1.4.1.21367.2006.7.101"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
id="id_4">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon confidentialityCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Clinical-Staff"/>
</rim:Name>
</rim:Classification>
<rim:Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="Document01" nodeRepresentation="CDAR2/IHE 1.0"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
id="id_5">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon formatCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="CDAR2/IHE 1.0"/>
</rim:Name>
</rim:Classification>
<rim: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">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon healthcareFacilityTypeCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Outpatient"/>
</rim:Name>
</rim:Classification>
<rim:Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="Document01" nodeRepresentation="General Medicine"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
id="id_7">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>Connect-a-thon practiceSettingCodes</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="General Medicine"/>
</rim:Name>
</rim:Classification>
<rim:Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="Document01" nodeRepresentation="34108-1"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
id="id_8">
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>LOINC</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="Outpatient Evaluation And Management"/>
</rim:Name>
</rim:Classification>
Like the Submission Set, the Document Entry has UniqueID and PatientID attributes. The identificationSchemes are different (between Submission Set and Document Entry) but the structure is the same.
<rim:ExternalIdentifier
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427"
value="ef77eeda67dd4a2^^^&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">
<rim:Name>
<rim:LocalizedString value="XDSDocumentEntry.patientId"/>
</rim:Name>
</rim:ExternalIdentifier>
<rim:ExternalIdentifier
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="1.2009.0827.08.33.5016"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
id="id_10" registryObject="Document01">
<rim:Name>
<rim:LocalizedString value="XDSDocumentEntry.uniqueId"/>
</rim:Name>
</rim:ExternalIdentifier>
</rim:ExtrinsicObject>
It was mentioned above in the discussion of the Submission Set that the RegistryPackage object on which it is based must be labeled to give it the semantics of Submission Set. The following Classification does that labeling. It can be coded as a peer of the RegistryPackage it labels (as is shown here) or nested inside. Same meaning. The XML attributes have the following meanings:
- classifiedObject="SubmissionSet01" - identifies the target of the classification (the Submission Set in this case)
- classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" - this value, defined by the XDS Profile, identifies the classifiedObject as a Submission Set
- id="ID_446196_1" - as mentioned above, classification have identify
- objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" - required redundant labeling
<rim:Classification classifiedObject="SubmissionSet01"
classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" id="ID_446196_1"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"/>
HasMember Association
So far we have created a Submission Set and a Document Entry. To make this submission correct and complete, we must link these two objects thereby making the Document Entry part of the Submission Set. This Association does that. The parts are:
- associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" - this is a HasMember association (the Submission Set has the member Document Entry)
- sourceObject="SubmissionSet01" - who has the member?
- targetObject="Document01" - who is the member?
- id="ID_446196_2" - Association objects, like many other, has identity
- objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association" - required redundant labeling
The SubmissionSetStatus slot is only used on HasMember associations linking Document Entry objects to the Submission Set.
<rim:Association
associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"
sourceObject="SubmissionSet01" targetObject="Document01" id="ID_446196_2"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association">
<rim:Slot name="SubmissionSetStatus">
<rim:ValueList>
<rim:Value>Original</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Association>
</rim:RegistryObjectList>
</lcm:SubmitObjectsRequest>
</xdsb:ProvideAndRegisterDocumentSetRequest>
Annotated Response
These examples were generated by the Public Registry.
Two possible responses can be received: success and failure. Here are examples.
Success
Not much can be said about this example. The status attribute gives the success/failure report.
<rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
Failure
There are many reasons for a failure. Table 4.1-11 Error Codes in Technical Framework volume 3 gives the complete list of error codes that may be returned.
Here is a failure returned back from the Document Registry because the documents were submitted for a Patient ID that is unknown to the Registry.
First the status is Failure with the required namespace on the value. This structure can contain multiple errors. RegistryErrorList is the wrapper around the list of errors.
<rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure">
<rs:RegistryErrorList>
This example contains a single error: single RegistryError element. The parts are:
- severity attribute, with proper namespace, labels this RegistryError structure as an error (as opposed to a warning)
- codeContext is a free text message explaining the problem
- errorCode is a text code taken from Table 4.1-11 Error Codes in Technical Framework volume 3
- location is unconstrained detail about where the error occured. I usually put a Java stack trace here since it is helpful in debugging.
<rs:RegistryError
codeContext="XDS Unknown Patient Id:
PatientId 1111111^^^&1.3.6.1.4.1.21367.2005.3.7&ISO is not known to the Registry"
errorCode="XDSUnknownPatientId"
location=""
severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>
</rs:RegistryErrorList>
</rs:RegistryResponse>