2.5 一般的なユースケース

Home ＞ Implementation ＞ Common Usage [usecases]

FHIR is a framework standard that defines a common way to solve healthcare problems, and provides a set of resources that can be used in many different ways. This page describes how certain common usage scenarios are implemented using the capabilities that FHIR defines.

In the PHR scenario, an Electronic Medical Record system (EMR, though many other names and acronyms are also used) provides a RESTful API that allows patients to access their own medical record via a common web portal or mobile application, usually provided by a third party. In this scenario, the PHR provider:

• Provides the patient with a login that identifies them (or links the patient record to an external identity provided by OpenID, Facebook, Google, etc.)
• Authenticates the client using an appropriate OAuth server for the login (possibly their own) and restricts the client to viewing records associated with the specific patient (or patients, where appropriate access has been arranged)

The EMR exposes a FHIR server that supports the search and read operations on the following resources:

1. the patient resource in order to provide demographics to the client. When a client searches patients with no search criteria, they get a list of all patients they have access too
2. search and read on the Document Reference resource to provide access to general patient documents in the form of PDFs etc. (PDFs are preferred)
3. search and read on a set of clinical resources potentially including Observation, DiagnosticReport, various Medication resources, AdverseReaction/AllergyIntolerance, CarePlan, and Condition

Here is the conformance Statement for this scenario: XML or JSON.

The EMR may also choose to provide additional functionality, such as shared access to patient records by relatives/carers, to allow the patient to upload their own documents, medication statements, observations (e.g. from patient monitoring devices) and/or to allow the patient to make appointments. This additional functionality will involve additional API capabilities to be implemented and exposed. The EMR server may also choose to expose the read, search and updates operation on the Security Event resource for the patient-specific records to allow patient review of record access. Note that all usage of the RESTful API should be logged in SecurityEvent resources.

One common way to integrate healthcare information from a variety of sources is to build a repository of documents around a patient record. Building a repository of documents allows for less stringent alignment around policy, procedures, and record-keeping/informatics standards.

The most widely adopted framework for sharing documents within institutions, regions, states or countries is IHE Cross-Enterprise Document Sharing (XDS). XDS allows for a federated system of repositories with a registry to provide co-ordinated access to the documents.

FHIR provides equivalent functionality to XDS that can be used to implement XDS behind the existing XDS.b interface, to provide a simpler mobile-friendly interface to an existing XDS ecosystem, or to link document sharing into other functionality provided through a FHIR interface.

The following FHIR Resources are involved in the XDS functionality:

• The DocumentReference resource describes a document that is located elsewhere. A document registry is a system that maintains a set of Document References
• The XDS profile provides specific XDS implementation detail for the more general DocumentReference resource
• The Binary support can be used to store the actual documents on a FHIR server. A repository is a system that stores the binary document in addition to Document References (or sometimes without)
• Patient, Practitioner and Organization resources provide support for identifying people and organizations
• The SecurityEvent resource tracks usage of the document registry and repository

At present, IHE is working with the FHIR project team to use FHIR for Mobile Health Documents (MHD).

Still to be done.