Difference between revisions of "Care Services Discovery"
| Line 1: | Line 1: | ||
| − | |||
__TOC__ | __TOC__ | ||
| Line 7: | Line 6: | ||
supported; this FreeBusy information would enable the development of a list of schedulable time | supported; this FreeBusy information would enable the development of a list of schedulable time | ||
slots for providers or services at specific facilities. | slots for providers or services at specific facilities. | ||
| + | |||
| + | The CSD profile describes four actors and the transactions between them: | ||
| + | # Service Finder – the Service Finder actor submits queries to the Care Services InfoManager, who returns the requested result(s). Queries may be expressed as invocations of “stored” queries, or (optionally) as ad hoc queries using the flexible XQuery standard, or (optionally) as iCalendar vFREEBUSY queries. | ||
| + | # Care Services InfoManager – the InfoManager actor has two roles. The InfoManager maintains a local cache of content that represents cross-referenced data from one or more Care Services Directory actors. The InfoManager periodically refreshes this cache by querying Directory actors for updated content. The InfoManager’s other role is to process inbound queries from Service Finder actors. These queries are executed against the cached content. | ||
| + | # Care Services Directory – the Directory actor is responsible for returning an XML document in response to a refresh request from a Care Services InfoManager. The response document contains content which has been inserted or updated in the directory since the last refresh and is expressed in the format defined by the CSD profile’s XML schema. | ||
| + | # Service Availability – the Service Availability actor responds to requests for the “busy” time for a provider offering a service at a specified facility or for a service at a specified facility. This busy data may be employed to determine the free time slots which may be scheduled. The format of the request and response is defined by the IETF CalDAV specification (RFC 4791). | ||
==Benefits== | ==Benefits== | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Because it maintains interlinked directory information, the CSD profile is able to respond to queries such as: | Because it maintains interlinked directory information, the CSD profile is able to respond to queries such as: | ||
*Which facilities are associated with which organizations? | *Which facilities are associated with which organizations? | ||
| − | *What services are provided at specific facilities or, conversely, where are the | + | *What services are provided at specific facilities or, conversely, where are the facilitiesthat provide a specified service? |
| − | |||
*Who are the providers associated with a particular organization; what services do they provide; at which facilities do they provide these services, and when? | *Who are the providers associated with a particular organization; what services do they provide; at which facilities do they provide these services, and when? | ||
*Within a specified date range, when are the schedulable time slots for the provider of a specific service? | *Within a specified date range, when are the schedulable time slots for the provider of a specific service? | ||
| + | |||
The CSD profile’s loosely coupled design and flexible querying capability means it can be deployed within a number of eHealth architectures and support a wide array of care workflows. | The CSD profile’s loosely coupled design and flexible querying capability means it can be deployed within a number of eHealth architectures and support a wide array of care workflows. | ||
Revision as of 12:24, 18 September 2014
Summary
The Care Services Discovery (CSD) profile supports queries across related directories containing data about: organizations, facilities, services and providers. Queries against an optional “FreeBusy” service are also supported; this FreeBusy information would enable the development of a list of schedulable time slots for providers or services at specific facilities.
The CSD profile describes four actors and the transactions between them:
- Service Finder – the Service Finder actor submits queries to the Care Services InfoManager, who returns the requested result(s). Queries may be expressed as invocations of “stored” queries, or (optionally) as ad hoc queries using the flexible XQuery standard, or (optionally) as iCalendar vFREEBUSY queries.
- Care Services InfoManager – the InfoManager actor has two roles. The InfoManager maintains a local cache of content that represents cross-referenced data from one or more Care Services Directory actors. The InfoManager periodically refreshes this cache by querying Directory actors for updated content. The InfoManager’s other role is to process inbound queries from Service Finder actors. These queries are executed against the cached content.
- Care Services Directory – the Directory actor is responsible for returning an XML document in response to a refresh request from a Care Services InfoManager. The response document contains content which has been inserted or updated in the directory since the last refresh and is expressed in the format defined by the CSD profile’s XML schema.
- Service Availability – the Service Availability actor responds to requests for the “busy” time for a provider offering a service at a specified facility or for a service at a specified facility. This busy data may be employed to determine the free time slots which may be scheduled. The format of the request and response is defined by the IETF CalDAV specification (RFC 4791).
Benefits
Because it maintains interlinked directory information, the CSD profile is able to respond to queries such as:
- Which facilities are associated with which organizations?
- What services are provided at specific facilities or, conversely, where are the facilitiesthat provide a specified service?
- Who are the providers associated with a particular organization; what services do they provide; at which facilities do they provide these services, and when?
- Within a specified date range, when are the schedulable time slots for the provider of a specific service?
The CSD profile’s loosely coupled design and flexible querying capability means it can be deployed within a number of eHealth architectures and support a wide array of care workflows.
Details
<A few paragraphs, if appropriate, providing more details (mostly in user-speak, not tech-speak) on what the profile does and how it works.>
<If the user might be familiar with the mechanisms used by the profile, you can mention them here. E.g. Evidence Documents is based on DICOM Structured Report (SR) Templates.>
<If the user might have an appreciation for the problems addressed in the profile, you can mention them here, but keep it short. E.g. Mapping HL7 Order fields to DICOM Modality Worklist attributes can be inconsistent in the marketplace, so Scheduled Workflow provides vendors with more detailed instructions.>
Systems Affected
<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>
- PACS systems may store, manage, and/or display Evidence Documents.
- Display systems may query, retrieve and display Evidence Documents.
- Reporting workstations may retrieve, process and include details from Evidence Documents in reports
Actors & Transactions:
<Insert an actor-transaction diagram, and or list of Content Definitions>
Specification
Profile Status: Trial Implementation
Documents:
<Provide direct links to the specific volumes or supplements, and list the volume sections relevant to this profile. This is a simple inventory of official normative and informative text. If you would like to provide a reading guide or walkthrough of what is in each of the different sections for implementers or users, do that in the Profile FAQ or the Profile Implementation Page linked below. If the profile uses transactions from multiple Tech. Frameworks, repeat the structure below.>
IHE Radiology Technical Framework:
Underlying Standards:
<list all the standards on which the profile is based; if possible with links to sources>
See Also
<The following sections can be left out if there is nothing to point to. This is just to show where such information can go.>
Related Profiles
<List profiles this one depends on, profiles that depend on this one, profiles that are synergistic with this one. Start with the name of the other profile as a link and then explain the relationship.>
- Reporting Workflow [RWF] may use Evidence Documents as inputs to the reporting process.
- Simple Image & Numeric Reports [SINR] may include data copied from Evidence Documents.
- Cross-enterprise Document Sharing for Imaging [XDS-I] can be used to share Evidence Documents between sites over a network.
- Portable Data for Imaging [PDI] can store Evidence Documents on media such as CDs.
- Import Reconciliation Workflow [IRWF] can fix patient ids, etc. of Evidence Documents when importing.
Consumer Information
The Profile FAQ Template answers typical questions about what the Profile does. <Replace the link with a link to the actual FAQ page for the Profile>
The Profile Purchasing Template describes considerations when purchasing equipment to deploy this Profile. <Replace the link with a link to the actual Purchasing page for the Profile>
Implementer Information
The Profile Implementation Template provides additional information about implementing this Profile in software. <Replace the link with a link to the actual Implementation page for the Profile>
Reference Articles
<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis). Go ahead, Google: IHE <Profile Name> abstract or Google: IHE <Profile Name> and under the "more" select "Scholar". You might be surprised. >
This page is based on the Profile Overview Template
Current: IT Infrastructure Technical Framework.