In the CDA R2 CCD implementation guide, a ClinicalDocument element (the root element of the document) is supposed to have an id element.
This id element is of the "II" datatype: http://wiki.hl7.no/index.php/R1:II
This states that the root attribute is to have an OID value, to identify the type of identification used in the extension attribute.
Now, when looking at the sample CCD document that HL7 provides we see:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="CDASchemas\cda\Schemas\CCD.xsl"?>
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd" >
...
<id root="db734647-fc99-424c-a864-7e3cda82e703"/>
...
</ClinicalDocument>
The root value db734647-fc99-424c-a864-7e3cda82e703 is not an OID. I'm not sure what it is, but it looks like a UUID perhaps? Anyway, is this a static value for all CCD documents, or will it differ from document to another? Why is the extension attribute not used, isn't that what identifies the document?
Note that throughout that same sample document I also see things like
<id root="2.16.840.1.113883.19.5" />
which seem to be OIDs (in the root attribute).
EDIT: The sample document I reference is from the HL7 CCD implementation guide, i.e it is from the official source, it is unlikely that they would have a glaring error in their sample file that nobody has noticed before.
Old question, I know, but I'm just learning about this stuff and I think I finally have my head wrapped around it.
The roots are basically like namespaces or domains in which the id will be valid and guaranteed to be unique. For example if your authority/organization is generating CDAs it will most likely have applied for a unique OID (the value you see in the root is an OID 2.16.840.1.113883.19.4).
So, for the example above,
<id root="2.16.840.1.113883.19.4" extension="abc266"/>
I'm going to guess that 2.16.840.1.113883.19 is the base OID for the authority sending out the CDA and the .4 is most likely the OID to indicate that this
<id>
is in fact the document's identifier (the authority defines these OID extensions under the base OID)
"extension" is the Unique Identifier value for this particular document.
In regards to your comment about the implementation guide not having glaring errors, I've found quite the opposite in trying to figure this stuff out...there are errors abound. I do believe the root is always to be an OID, the extensions are usually UUIDs or some other unique ID.
I am working on the same thing myself. An example I received from our EHR certifying authority had the id's root looking like an OID. It was "2.16.840.1.113883.3.72".
Here is a link that may help somewhat:
http://www.ihe.net/Technical_Framework/upload/ihe_lab_TF_rel2-3.pdf
I copied the relevant text below.
This element SHALL be present. It
represents the unique instance
identifier of the clinical document.
The combination of the root and
extension attributes SHALL provide a
globally unique identifier. Example:
<id root="2.16.840.1.113883.19.4" extension="abc266"/>
You can download the CDA Release 2 documentation here:
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
Note: you will have to create an account, but not a paid account. Also, when I forgot my password, they emailed it in plain text to me. Don't use your secure password here.
In datatypes-base.xsd, you can see an explanation of II type. Root is a UID, and there are 2 types of UID. An OID and a UUID.
UUIDs are GUIDs (your example).
OIDs are HL7 designated IDs. You can file for an organizational OID, and you have control over any leaf OIDs from that point. Following pattern "[0-2](\.(0|[1-9][0-9]*))*"
Between the root and extension (string), the II should be universally unique. An OID can be unique by itself. A couple examples.
OID "2.16.840.1.113883" is Hl7 (https://www.hl7.org/oid/index.cfm). Leaf ".10.20.22" is HL7 Health Story Templates. Leaf ".1.2" is a Continuity Of Care Document.
<id root="2.16.840.1.113883.10.20.22.1.2" /> is globally unique for a CCD template, extension unneeded
OID "2.16.840.1.113883.5" is HL7 V3 Code Systems. ".1" is Administrative Gender
<id root="2.16.840.1.113883.5.1" extension="M" /> is globally unique for Male
That gives you two options for generating an II for your clinical document. You can generate your own GUID. Or you can use any local identifier, if you have a meaningful ID within an OID/leaf that your organization controls. Pulling the top OID from the hl7 registry ("2.16.840.1.113883.5.3" is external users; ".1" is ProVation) as an example:
They could define leafs as needed; and each time they send a document, it would reference the same unique document. Theoretically: 100=documents; 100.2=clinical documents; extension=databaseIdentityColumn.
<id root="2.16.840.1.113883.5.3.1.100.2" extension="1" /> = first document they created
<id root="2.16.840.1.113883.5.3.1.100.2" extension="15" /> = 15th document they created
It's also perfectly valid to use OID only format, as long as it's globally unique.
<id root="2.16.840.1.113883.5.3.1.100.2.15" /> = 15th document they created
Similar to a globally unique SSN
<id root="2.16.840.1.113883.4.1" extension="111-11-1111" />
Then locally defined patient identifier could be .12=patient chart
<id root="2.16.840.1.113883.5.3.1.12" extension="ZZ1234-111111" />
According to these two links:
http://tl7.intelliware.ca/public/messages/dataTypes/ii.faces and http://cdatools.com/infocenter/index.jsp?topic=/org.openhealthtools.mdht.uml.cda.consol.doc/classes/GeneralHeaderConstraints.html
the "II" datatype accepts both OID and UUID in its root element.
Can someone direct me to the official documentation explaining this?
Sidenote: The lack of proper documentation and knowledge available online regarding HL7 is quite disappointing, given the fact that it is widely used.
I know this is an old post, but like user453441 said, HL7 info is hard to come by.
Regarding the <id> element, here is what I believe is going on:
According to some learning materials I have been given to read at work, the element is a "Document Identifier". It is a
"unique identifier for (the) document instance. The (id) is normally generated by the document creator."
My interpretation is that this element is to be used for security and verification purposes. I believe that the element that is a child of the main <Clinical Document> element is used to show the CDA recipient that this document did indeed originate from the expected origin. You, as a CDA sender, would have a unique ID of some sort (there doesn't seem to be a standard, but getting an OID for your organization would be helpful).
The root attribute of the <id> element is the unique identifier for the whole document, the unique ID for your organization. There is also an extension attribute that can be used to uniquely identify individual sections of the CDA. You mentioned there is more than one attribute in the CDA, this is why. The extension attribute could be used to identify, for example, the <assignedAuthor>. It appears that all children of any Participation element uses this <id> element.
Hope this helps.
Edit: After reading further, I have a couple more details. The root attribute of the <id> element
"...represents the unique instance identifier (UID)."
I am getting these quotes from learning materials from the "Asociacion HL7 Argentina -HL7". Their example of this uses a case number and a version sequencer for the extension attribute. That way, two different organizations could use the same extension, but since they have different UIDs in the root attribute, they are still different.
The 'id' attribute in the the ClinicalDocument class of a CDA document should hold a unique id for the document.
For an II datatype then the "root" should always be an OID, the extension can be any unique string. I would suggest that there is an error in your example XML ( where was this sourced from ).
It goes without saying that within the CDA document there will be many different OIDs used depending on the object they are used to Id.
When you are looking in the CDA specifications, what has already been mentioned, you see that the datatype of the ClinicalDocument.id element is II (Instance Identifier).
If you are looking into the datatype definition (can be found in the datatypes-base.xsd file), you will find the following:
<xs:complexType name="II">
<xs:annotation>
<xs:documentation>
An identifier that uniquely identifies a thing or object.
Examples are object identifier for HL7 RIM objects,
medical record number, order id, service catalog item id,
Vehicle Identification Number (VIN), etc. Instance
identifiers are defined based on ISO object identifiers.
</xs:documentation>
<xs:appinfo>
<sch:pattern name="validate II">
<sch:rule abstract="true" id="rule-II">
<sch:report test="(#root or #nullFlavor) and not(#root and #nullFlavor)">
A root component is required or else the II value is NULL.
</sch:report>
</sch:rule>
</sch:pattern>
</xs:appinfo>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ANY">
<xs:attribute name="root" type="uid" use="optional">
<xs:annotation>
<xs:documentation>
A unique identifier that guarantees the global uniqueness
of the instance identifier. The root alone may be the
entire instance identifier.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="extension" type="st" use="optional">
<xs:annotation>
<xs:documentation>
A character string as a unique identifier within the
scope of the identifier root.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="assigningAuthorityName" type="st" use="optional">
<xs:annotation>
<xs:documentation>
A human readable name or mnemonic for the assigning
authority. This name may be provided solely for the
convenience of unaided humans interpreting an II value
and can have no computational meaning. Note: no
automated processing must depend on the assigning
authority name to be present in any form.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="displayable" type="bl" use="optional">
<xs:annotation>
<xs:documentation>
Specifies if the identifier is intended for human
display and data entry (displayable = true) as
opposed to pure machine interoperation (displayable
= false).
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
Here you can see that the root attribute has to be a uid with the following documentation:
A unique identifier that guarantees the global uniqueness
of the instance identifier. The root alone may be the
entire instance identifier.
Related
I am currently setting up my realtime firebase database to my iOS application.
It is my first time trying to structure user data in a firebase database, and I am really, really struggling with understanding a few key things.
A bit of context to my application's database needs:
When a new user is created, the attributes assigned directly to the user are:
Age
Email
Username
Nationality
Later on, the user needs the option of creating personal diaries!
Each of these diaries being arrays/lists of objects... Where each object in a diary furthermore holds a few attributes in a list/array.
After reading everything I could find anywhere, I picture my database something like this:
I am terribly sorry if it becomes too specific - I will try to make the question as open as possible:
My question is:
How to create the different "children" programmatically and how to find the keys leading back to them, so I can refer to them at other times again? (when editing an attribute in a child).
A few methods I have tried:
setValue([ArrayOfObjects]) --> This creates the desired array, but I can't seem to find e.g. index 3 in this array, to allow user to change his/her email later on.
childByAutoID() --> This as well creates my array, but gives several other problems: User can only store one diary, still can't find the paths to specific indexes...
setValue(), andPriority() --> Can't seem to make the priority function. (Is this function also outdated??)
And a few more...
If anyone can tell me how to achieve just the first few steps in setting up my database structure, I will be forever grateful - I have spent literally all day on it and I am not moving forward ...
Or, at least tell me, if I am on the right track regarding my desired setup of the database. Is it flat enough? Is there a smarter way to store all these user created lists?
Thank you so much! :-)
I don't know Swift so my examples are in Dart but the methods are similar I believe.
First off, I would split the Users node into two. One to hold the user data, which is normally pretty static, and the other to hold the diaries. You would use the same uid key as reference to both. This way you have less nesting to worry about and therefore it is much easier to CRUD the data. If you are using Firebase to authenticate your users then I would use the unique key that Firebase creates for each user as the keys for these two nodes.
Then...
To create a user data node record the Dart code would be something like:
referenceUserData.child(<authenticated user id>).set({
"age": <age value>,
"email": <email value>,
"name": <name value>,
});
To create a user diary node object record the Dart code would be something like:
referenceUserData.child(<authenticated user id>).child(<diary key>).child(<diary object key>).set({
"object info value 1": <object value>,
"object info value 2": <object value>,
"object info value 3": <object value>,
});
You could also create all the object records at once by writing them as a List (array) using .set().
You also need to decide what your diary key should be. You could use Firebase to generate a unique key by using .push().set().
To read eg. the user data then your call could be:
referenceUserData
.child(<authenticated user id>)
.once()
.then(
(DataSnapshot snapshot) {
print(snapshot.key);
if (snapshot.value != null) {
print(snapshot.value);
<code to process your snapshot value>
}
};
BTW, 'priority' is legacy from the early days of Firebase RTDB so I wouldn't try to use it.
I'm trying to get values for PT_DOUBLE and PT_CLSID custom property data types using Microsoft Graph. I have no trouble getting custom properties for PT_LONG (Integer) or PT_UNICODE (String). Integer and String does not work for PT_DOUBLE and PT_CLSID properties, and I get this error:
ErrorInvalidExtendedProperty: The extended property attribute combination is invalid.
The documentation on supported data types is not very clear.
Here's a sample request that works for PT_UNICODE and PT_LONG props:
https://outlook.office.com/api/v2.0/me/contactfolders/{id}/contacts?
$top=1&
$expand=SingleValueExtendedProperties($filter=
(PropertyId eq 'String {1A417774-4779-47C1-9851-E42057495FCA} Name InlineLinks')+OR+
(PropertyId eq 'String {1A417774-4779-47C1-9851-E42057495FCA} Name XrmCompanyPeople')+OR+
(PropertyId eq 'Integer {1A417774-4779-47C1-9851-E42057495FCA} Name XrmContactType'))
I can live without PT_DOUBLE, but I really need to access these PT_CLSID props (String and Guid do not work):
XrmContactId: Tag = 0x86680048;
DASL: http://schemas.microsoft.com/mapi/string/{1A417774-4779-47C1-9851-E42057495FCA}/XrmContactId/0x00000048;
Kind: MNID_STRING
XrmId: Tag = 0x86680048;
DASL: http://schemas.microsoft.com/mapi/string/{1A417774-4779-47C1-9851-E42057495FCA}/XrmId/0x00000048;
Kind: MNID_STRING
Does anyone know the data type name for PT_CLSID or list of supported data types for Microsoft Graph? The Exchange Server Protocols Master Property List is painful to read through and it didn't give me any insights.
For SingleValueLegacyExtendedProperty, both the PropertyID and Value elements are strings.
One bit of clarification, the API you're calling here is the Outlook API and not Graph. While they provide similar functionality, they are distinct endpoints. Extended Properties in Graph also only supports string values.
https://hc.apache.org/httpcomponents-client-4.3.x/httpclient/apidocs/org/apache/http/client/utils/URLEncodedUtils.html#parse(java.net.URI,%20java.lang.String)
why not return Map< String, List< String > >
if it returns Map, user can easily query by key to get whatever they want.
otherwise user should iterator the whole list to find what they want.
Thanks
Because this is a list. If you read carefully the explanation, says:
Returns a list of NameValuePairs as built from the URI's query portion. For example, a URI of http://example.org/path/to/file?a=1&b=2&c=3 would return a list of three NameValuePairs, one for a=1, one for b=2, and one for c=3.
That means that you cannot use a list to acces by value, because these type of data structures aren't designed for that. They doesn't have any "key" to use.
In this website, Jon Skeet wrote a very clear answer about you cannot use a shortcut to acces a List<NameValuePair> value using a name or a key or for similar structures.
Here you can check the post: Get ArrayList<NameValuePair> value by name
Inside of the same post, you'll see different options to solve your problem. (Or could guide to you to find the solution)
How to query an item by name? I thought this might work the same as looking up a customer by name, but it seems like not.
For .net you can refer to the class library documentation here:
http://developer-static.intuit.com/SDKDocs/QBV2Doc/IntuitDataServicesSDK/
If you go to ItemQuery, you will se it exposes ItemElementName of return type ItemChoiceType4 enum.
If you go to the ItemChoiceType4 details, You will see it exposes, IteratorId and StartPage.
As mentioned above, Items cannot be queried by name.
Similarly for customer query on name, you can get details that it exposes Item1ElementName which returns Item1ChoiceType enum.
For all entities similarly you can search.
Using items will not be so elusive then. :)
Also, for each entity for QBD, you can reference the docs too and refer to Query Attributes section for details.
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/v2/0500_quickbooks_windows/0600_object_reference
QBD Items can't be retrieved by name
Ref QueryFilter Docs -
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/v2/0500_quickbooks_windows/0600_object_reference/item#Retrieving_Items_Using_a_Query_Filter
I have a doubt in using castor mapping.
I know Castor will look for classes with the same name as that of element name. I have my castor mapping ready and it is working fine.
My doubt is, what if an element is received as null [I mean no value is being passed]? Castor will try to instantiate the class and assign null? or will it skip those classes?
If it tries to create an instance of that class, what performance are we going to loose? something to discard or does it have much impact on performance?
EDIT-Including the XML
<Order>
<Activity>
<ActivityID>String</ActivityID>
<ActivityName>String</ActivityName>
<CurrentActivityInd>String</CurrentActivityInd>
<Description>String</Description>
<Reason>String</Reason>
<StartDateTime>2001-12-17T09:30:47Z</StartDateTime>
<EndDateTime>2001-12-17T09:30:47Z</EndDateTime>
<Status>String</Status>
<Action>String</Action>
<Owner>String</Owner>
</Activity> </Order>
Above is just a part of my XML. "Order can have any number of activity child within it".My question is,
What if I pass the XML like without any value? Will it instantiate Order and Activity class or Order class alone or none of the two?
Thanks!