2nd DSTU Draft For Comment

This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

U.S. Data Access Framework (DAF) Patient Profile (Conformance Package)

Scope and Usage

This profile sets expectations for use of the Patient resource within the Data Access Framework (DAF) Implementation Guide. This profile identifies which core elements,extensions,vocabularies and value sets must be supported by DAF actors.

For the purposes of this profile, Supported means the following:

SearchParameters:

DAF Query Requestor (client) SHALL be capable of querying the Patient resource using one or more of the search parameters for data elements tagged as MUST SUPPORT in this profile.
DAF Query Responder (server) SHALL be capable of receiving the queries submitted by the DAF Query Requestor and provide Query Results or error responses per the FHIR specifications.
DAF Query Responder MAY provide valid or error responses when the query parameters submitted contain data elements which are not tagged as MUST SUPPORT by this profile.

Query Results:

Query Results returned by DAF Query Responder SHOULD contain the data elements identified as MUST SUPPORT in the profile.
Query Results returned MAY contain data elements not tagged as MUST SUPPORT by the this profile.
Query Requestor SHALL process the Query Results containing additional data elements without indicating that the response is an erroneous response.

Missing Information:

When Query Results do not contain a particular data element identified as MUST SUPPORT, Query Requestors SHALL interpret the results to mean that the Query Responder did not have information and there is no further qualifying information as to why the information is missing.
In cases, where the Query Responder knows precisely the reason why the data is missing (e.g notasked in the data-absent-reason value set), then Query Responders MAY provide this additional information using the extension element as part of the data element. Query Requestors SHALL correctly process the data-absent-reason extension without rejecting the response as an erroneous response.

Relationship to Meaningful Use

The DAF Patient profile provides a mapping for the following Meaningful Use data elements to FHIR data elements.

Meaningful Use Data Element Name	FHIR Resource Mapping
Name	Patient.name
Patient Identifiers	Patient.identifier
Gender	Patient.gender
Date of Birth	Patient.birthDate
Race	Patient.extension(us-core-race)
Ethnicity	Patient.extension(us-core-ethnicity)
Preferred Language	Patient.communication
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

Meaningful Use Data Element Name

FHIR Resource Mapping

Name

Patient.name

Patient Identifiers

Patient.identifier

Gender

Patient.gender

Date of Birth

Patient.birthDate

Race

Patient.extension(us-core-race)

Ethnicity

Patient.extension(us-core-ethnicity)

Preferred Language

Patient.communication

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

Boundaries and Relationships

This profile relies on the use of other profiles, some required, others available for use "when necessary":

US Core which defines common properties related to Patient such as race and ethnicity.
Extensions defines other extensions such as birthPlace, patient-mothers-maiden-name which are used by the profile
FHIR Extensibility defines how extensions can be applied to FHIR resources and data types. Specifically the data-absent-reason extension is used to code data elements with missing information when appropriate.

Profile Details

Profiles:
DAFPatient	Defines constraints and extensions on the patient resource for use in querying and retrieving patient demographic information. : U.S. Data Access Framework (DAF) Patient Profile

Search Parameters

Search parameters defined by this package. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Paths	Source
age	number	Computation based search where the query requestor intends to search based on age rather than the actual birth date.	null	XML / JSON
birthOrderBoolean	token	Search based on whether a patient was part of multiple births or not.	null	XML / JSON
birthOrderInteger	number	Search based on birth order if the patient was part of multiple births.	null	XML / JSON
city	string	Search based on city	null	XML / JSON
ethnicity	token	The ethnicity of the patient	null	XML / JSON
mothersMaidenName	string	Patient's mother's maiden name	null	XML / JSON
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.)	null	XML / JSON
race	token	The race of the patient	null	XML / JSON
streetAddress	string	Search based on street address	null	XML / JSON
telecom	string	Search based on telecom value	null	XML / JSON
zipcode	string	Search based on zipcode	null	XML / JSON

Example Usage Scenarios

The following are example usage scenarios for the DAF Patient profile:

Query for a Patient demographic information using identifiers such as MRN
Query for a Patient demographic information using first name, last name etc.
Query for Patients based on race, ethnicity, gender etc.
Query for Patients based on geographical area such as city, state, zipcode information
Query for Patients less than 5 years
Query for Patients between ages of 25 and 50

Additional Implementation Guidance

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 have to 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. Since DAF profiles deal with queries of Patient data, identifiers play a critical role to identify the right resources to be returned. So all DAF Responders MUST return the Patient.identifier element as part of the Patient resource and further Patient.identifier.system and Patient.identifier.value MUST be populated.

Patient Matching: Patient Matching rules and criteria have to be evaluated by the implementing organization and have to comply with local policies and regulations. Query Requestors will have to deal with result sets that can return zero,one or more Patient Resources in response to a query.

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.

Coding Race Extension: Instances SHALL return the codes corresponding to one of "American Indian or Alaska Native", "Asian", "Black or African American", "Native Hawaiian or Other Pacific Islander", "White" in the first race element within the Patient resource. Instances can contain detailed race categories that can be rolled up to the above five categories as part of the subsequent race data elements.

Coding Ethnicity: Instances SHALL only use the code "2135-2" representing "Hispanic or Latino" or the code "2186-5" representing "Not Hispanic or Latino" from the Ethnicity Codesystem.

© HL7.org 2011+. FHIR DSTU (v0.4.0-4167) generated on Mon, Feb 23, 2015 09:22+1100.
Links: What's a DSTU? | Version History | Compare to DSTU1 | | Propose a change