The IHE ITI committee last week approved the Patient Demographics Query for Mobile (PDQm) profile go forward to Trial Implementation. This puts it on track for testing at the USA Connectathon in Cleveland. This is the first Profile of the new FHIR core standard. Both are in a trail state, so it is possible things will change. But these both are based on very mature concepts.
The executive summary is that this is a very minimal profile of the HL7 FHIR Patient resource. Two items have been made mandatory, where the FHIR spec leaves them potentially optional. One extension was added to support the pediatrics use-case that is an option in PDQ. Otherwise it is a simple FHIR 'GET' transaction, aka Query, that returns a Bundle (aka Atom Feed) of the resulting matching entries.
Use-case for PDQm
The Patient Demographics Query for Mobile (PDQm) Profile defines a lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to mobile applications and lightweight browser based applications.
- The functionality is identical to the PDQ Profile described in the ITI TF-1:8. The differences are transport and messaging format of messages and queries. The profile leverages HTTP transport, and the JavaScript Object Notation (JSON), Simple-XML, and Representational State Transfer (REST). The payload format is defined by the HL7 Fast Health Interoperable Resources (FHIR) draft standard.
Using these patterns, the PDQm Profile exposes the functionality of a patient demographics supplier to mobile applications and lightweight browser applications.
The following list provides a few examples of how PDQm might be leveraged by implementers:
- A health portal securely exposing demographics data to browser based plugins
- Medical devices which need to access patient demographic information
- Mobile devices used by physicians (example bedside eCharts) which need to establish patient context by scanning a bracelet
- Web based EHR/EMR applications which wish to provide dynamic updates of patient demographic information such as a non-postback search, additional demographic detail, etc.
- Any low resource application which exposes patient demographic search functionality
- Any application using the MHD Profile to access documents may use PDQm to find an appropriate patient identifier
- This supplement is intended to be fully compliant with the HL7 FHIR specification, providing only use-case driven constraints to aid with interoperability, deterministic results, and compatibility with existing PDQ and PDQv3 Profiles.
Currently the HL7 FHIR standard is in “Draft Standard for Test Use” (DSTU) and may experience a large amount of change during this phase. Readers are advised that, while the profiled components in this supplement may not accurately reflect the most recent version of the FHIR standard, implementations of PDQm will be tested as specified in this supplement. Changes to the FHIR DSTU will be integrated into this supplement via the formal IHE Change Proposal (CP) process.
Using the FHIR Patient resource, IHE needed only profile two elements. IHE sets the patient name and identifier as mandatory, whereas the core FHIR allows them to be empty. This is the FHIR Patient Resource as it is used by PDQm.
FHIR Patient Resource ++
Pediatrics Demographic Option
PDQm has usecases to support new-born that have not been fully identified, and thus require that the mother’s maiden name be included in their Patient resource. This was introduced to PDQ with a Pediatrics Option. This use-case is not currently supported by the FHIR DSTU, so IHE has extended the Patient resource to include this. IHE will be bringing the use-case to HL7 for proper handling (recognizing that it is most likely the mothers name, not the mother’s maiden name that is desired).
...
"extensionDefn" : [
{
"code" : "mothersMaidenName",
"contextType" : "resource",
"context" : [ "Patient" ],
"definition" : {
"short" : "Patient's mother's maiden name",
"formal" : "The name of the patient's mother",
"min" : 0,
"max" : 1,
"type" : [
{
"code" : "HumanName"
}
],
"isModifier" : false
}
}
]
...
PDQm as a RESTful API to a mature PDQ and PIX environment.
PDQm can be viewed as an API to a classic PDQ or PDQ v3 environment. Same PDQ use cases and interactions, using the FHIR encoding for the transaction from the mobile consumer. This diagram shows an implementation of a gateway that converts the PDQm into a normal PDQ transaction via a gateway.
PDQ attributes
The following table shows the attribute mapping between PDQ, PDQ v3, and PDQm.
Abstract Field
|
PDQ
|
PDQ HL7v3
|
PDQm
|
Identifier List
|
PID.3 and PID.18
|
Id
|
identifier
|
Name(s)
|
PID.5 and PID.9
|
Name
|
name
|
Date / Time of Birth
|
PID.7
|
birthTime
|
birthDate
|
Gender
|
PID.8
|
administrativeGenderCode
|
gender
|
Address(es)
|
PID.11
|
Addr
|
address
|
Telecommunications Address(es)
|
PID.13 and PID.14
|
Telecom
|
telecom
|
Language(s) of communication
|
PID.15
|
languageCommunication
|
communication
|
Marital Status
|
PID.16
|
maritalStatusCode
|
maritalStatus
|
Non-Medical Identifiers
|
PID.19 and PID.20
|
asOtherIds
|
identifier
|
Death Date/Time
|
PID.29
|
deceasedTime
|
deceasedDateTime
|
Mother’s Maiden Name
|
PID.6
|
personalRelationship.name
|
See ITI TF-2c: 3.78.4.2.2.2
|
Patient Birth Order
|
PID.25
|
multipleBirthOrderNumber
|
multipleBirthInteger
|
PDQ Query Parameters
And the query parameters, mapped between the three
Abstract Parameter
|
PDQ
|
PDQ HL7v3
|
PDQm
|
Identifier List
|
@PID.3 and @PID.18
|
livingSubjectId
|
Identifier
|
Name
|
@PID.5
|
livingSubjectName
|
given and family
|
Date / Time of Birth
|
@PID.7
|
livingSubjectBirthTime
|
Birthdate
|
Gender
|
@PID.8
|
livingSubjectAdministrativeGender
|
Gender
|
Address
|
@PID.11
|
patientAddress
|
Address
|
Domains to be Returned
|
QPD-8
|
otherIDsScopingOrganization
|
See ITI TF-2c:3.78.4.1.2.4
|
Mother’s Maiden Name
|
@PID.6
|
mothersMaidenName
|
mothersMaidenName.given and mothersMaidenName.family
|
Patient Telecommunications Addresses
|
@PID.13
|
patientTelecom
|
Telecom
|
The result of a query is a “Bundle”, which for XML encoding is derived in FHIR from the standards based ATOM feed.
Examples
Here is a sample Query, in HTTP form, requesting JSON format be returned, all Male patients with the Given name “John” and the Family name “Smith”.
GET http://pdm-sample:8080/iti-y1/Patient?_format=application/json+fhir&gender=M&family=Smith&given=John&count=10
User-Agent: Fiddler
Host: pdq-sample:8080
Here is a sample result. Amazingly there is only one John Smith.
HTTP/1.1 200 OK
Connection: close
Content-Type: application/json+fhir; charset=UTF-8
Content-Length: 2683
Date: Sun, 06 Apr 2014 20:38:23 GMT
Expires: Sat, 05 Apr 2014 20:38:20 GMT
{
"resourceType" : "Bundle",
"title" : "Search results for resource type Patient",
"id" : "urn:uuid:c179d5bd-e81e-4fe0-981a-46f6c6588f",
"link" : [
{
"href" : "http://pdm-sample:8080/iti-y1/Patient?_format=application/json+fhir&gender=M&family=Smith&given=John&count=10",
"rel" : "self"
}
],
"updated" : "2014-04-06T20:38:23Z",
"totalResults" : "1",
"entry" : [
{
"title" : "Patient \"1\"",
"id" : "http://pdm-sample:8080/iti-y1/Patient/1",
"link" : [
{
"href" : "http://pdm-sample:8080/iti-y1/Patient/1",
"rel" : "self"
}
],
"updated" : "2014-03-11T20:34:55Z",
"content" : {
"resourceType" : "Patient",
"text" : {
"status" : "generated",
"div" : "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<div xmlns=\"http://www.w3.org/1999/xhtml\">John Smith (Male) - 1974-12-25</div>"
},
"identifier" : [
{
"use" : "usual",
"system" : "urn:oid:1.2.36.146.595.217.0.1",
"value" : "12345",
"assigner" : {
"display" : "Acme Healthcare"
}
}
],
"name" : [
{
"use" : "official",
"family" : [
"Smith"
],
"given" : [
"John",
"James"
]
},
{
"use" : "usual",
"given" : [
"James"
]
}
],
"telecom" : [
{
"use" : "home"
},
{
"system" : "phone",
"value" : "+1(202)555-6474",
"use" : "work"
}
],
"gender" : {
"coding" : [
{
"system" : "http://hl7.org/fhir/v3/AdministrativeGender",
"code" : "M",
"display" : "Male"
}
]
},
"birthDate" : "1974-12-25",
"deceasedDateTime" : null,
"address" : [
{
"use" : "home",
"line" : [
"123 Main St. West Unit 33"
],
"city" : "Chicago",
"state" : "IL",
"zip" : "00000"
}
],
"managingOrganization" : {
"display" : "ACME Medical Centres"
},
"active" : true
},
"summary" : "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<div xmlns=\"http://www.w3.org/1999/xhtml\">John Smith (Male) - 1974-12-25</div>"
}
]
}
Conclusion
IHE won't be the only one to profile FHIR. This supplement helps give synergy between the two PDQ flavors, providing a new flavor. The advantage of this new flavor is that applications can more easily process it. It doesn't really make the server job easier
Blog References on mHealth
- Healthcare access control scope constraints on OAuth tokens
- mHealth Identities using trusted intermediary
- getting to mHealth solutions - real People
- getting to mHealth solutions - Users
- Internet User Authorization: why and where
- Security Considerations: Healthcare RESTful Resource specifications
- Privacy and Security in Designing an mHealth Application
- mHealth Solution
- Security Considerations: Healthcare RESTful Resource specifications
- IHE efforts in RESTful security
- IHE mHealth Hackathon
- The Magic of FHIR – The HL7 movement toward REST resources, away from v3 and v2
- IHE Mobile access to Health Documents - Trial Implementation
No comments:
Post a Comment