FHIM::Datatypes::Datatypes Diagram Datatypes This diagram displays all the classes in the FHIM Datatypes package. The FHIM data types are closely aligned with the HL7 FHIR datatypes, which we have found to be the most robust and useful of the datatypes specified by existing Health IT standards. Previously, the FHIM was more closely aligned with the HL7 Version 3 data types, albeit the FHIM datatypes were simplified so that they might be more easily resolved into implementable specifications. Therefore, where a FHIM data type maps to an HL7 V3 data type, we have placed the HL7 data type mnemonic as a keyword, so for example, Person Name has a <> keyword.It is important to keep in mind that many of these data types will not necessarily be implemented directly, but rather would be substituted with the appropriate data type in the target paradigm. A note about Person Name is in order: We found the HL7 V3 notion that a person’s given name is an ordered list of names rather than a first name and middle name as traditionally modeled to be a useful construct. But we found that HL7’s modeling each part of the name separately to be overly complex, so we have modeled a single structure made up of several attributes each of which is a string. Similarly for addresses, we found HL7’s modeling each part of the address separately to be overly complex, so we have modeled a single structure made up of several attributes each of which is a string. Notably, the street portion of the address is simply line1, line2, and line3 rather than modeling each part of the street line separately.However, unlike our approach for Person Name, for both addresses and telecommunications addresses, we chose a hybrid approach for the use code. We include an address type (the values of which come from the HL7 V3 vocabulary), and we explicitly model the use of the data element in the domain model. For example, Person has both a primaryHomeAddress and a workAddress. The Address.addressTypeCode property would be set to the appropriate value accordingly. This approach was taken in order to explicitly account for the concepts in the logical model (for example, it makes no sense for a hospital to have a home phone number), while acknowledging that phone numbers, addresses, email addresses, etc. will likely be implemented using a mixed bag of addresses, each of which would have some sort of type code.
