This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions
This profile sets expectations for use of the Patient resource within the Data Access Framework (DAF) Implementation Guide. This profile identifies which core data elements,extensions,vocabularies and value sets must be Supported by DAF actors. For the definition of Supported please refer to DAF FHIR IG. The data elements identified by the profile are based on ONC 2014 Edition S&CC and DAF use cases. The mappings between the ONC 2014 Edition S&CC data elements and DAF data elements are captured in the table below, where the first column identifies the ONC 2014 Edition S&CC data element name, the second column maps the ONC 2014 Edition S&CC data elements to DAF data elements which are derived from ONC 2014 Edition S&CC standards and DAF use cases and lastly the third column identifies the mapping to FHIR resources and attributes.
The DAF Patient profile mapping to Meaningful Use data elements and FHIR Resources are as shown below.
Meaningful Use Data Element Name | Mapping to Priority DAF Data Elements | FHIR Resource Mapping |
---|---|---|
Patient Name | Patient Name | Patient.name |
Sex | Gender | Patient.gender |
Date of Birth | Date of Birth | Patient.birthDate |
Race | Race | Patient.extension(us-core-race) |
Ethnicity | Ethnicity | Patient.extension(us-core-ethnicity) |
Preferred Language | Preferred Language | Patient.communication.preferred |
Patient Identifiers | Patient.identifier | |
Multiple Birth Indicator | Patient.multipleBirthBoolean | |
Birth Order | Patient.multipleBirthInteger | |
Mother's Maiden Name | Patient.extension(patient-mothers-maiden-name) | |
Address | Patient.address | |
Telephone | Patient.telecom | |
Marital Status | Patient.maritalStatus | |
Birth Place | Patient.extension(birthplace) | |
Religious Affiliation | Patient.extension(religion) | |
Guardian | Patient.contact |
This profile relies on the following other profiles:
Profiles: | |
DAFPatient | Defines constraints and extensions on the patient resource for use in querying and retrieving patient demographic information. |
Search parameters defined by this package. See Searching for more information about searching in REST, messaging, and services.
Name | Type | Description | Paths | Source |
name | token | The name of a patient that matches a given name or a family name or the name represented by the text element. (Note: This overrides the base Patient resource name search parameter behavior.) | XML / JSON |
The full list of supported patient search parameters are can be accessed at DAF Requestor conformance expectations and DAF Responder conformance expectations.
The following are example usage scenarios for the DAF Patient profile:
Implementers need to be mindful of the following during their implementation
Patient Identifiers: Patient Identifiers are represented as part of the Patient.identifier data element. Identifiers must be scoped using a URI data type represented within the Patient.identifier.system element. If systems are using OID's to scope their patient identifiers, then OID's can be converted to URI's per RFC-3001. However, systems are encouraged to adopt parallel URIs and map to allow the benefits of human readability and resolvability. Since DAF profiles deal with queries of Patient data, identifiers play a critical role in identifying the right resources to be queried and returned.
Representing Patient Names: Patient Names are represented using the HumanName datatype. Per the FHIR specification, the first name is represented using the first occurrence of the element HumanName.given element. Middle names and other parts of the name can be represented using subsequent occurrences of the HumanName.given element.
Specifying multiple race codes: Many systems may capture race codes at a very granular level which can be rolled up to higher level race codes such as "Asian", "White" etc. In cases where these systems intend to include these granular race codes in addition to the higher level race codes permitted by the value set they can do so by using the coding element which can be repeated as many times as needed within the race element.
Capturing BirthPlace: Many systems may only capture the birth place as a city name, or a state name or a county name instead of using a highly structured Address data type. In these cases these systems should use the address.text field to record the birth place.
See DAF FHIR IG for implementation guidance common to all profiles.