[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OMG HL7 "Integrated" Service Descriptions Document
From: | Rubin, Ken (EDS) [SMTP:Ken.Rubin@med.va.gov] | ||
To: | servicesBOF@lists.hl7.org; healthcare@omg.org | ||
Cc: | |||
Subject: | "Integrated" Service Descriptions Document | ||
All: Okay, here is what we have in to date. Thanks to
Virinder, Heath, Note that in some cases we have competing submissions that
will need to I expect that we will have a few more descriptions trickle
in over the We also have what appears to be positive movement on the
collaborative - Ken <<Integrated Service Specification Descriptions v1.0.doc>> |
Service “Short” Name |
Organizations with Registered
Interest |
Description |
Collaboration/Coordination of Terminology |
NLM |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Provider Directory |
HL7
|
Service “Short” Name: Provider Directory Organizations with
Registered Interest: HL7
Purpose: A directory holding details of healthcare providers including their identifiers, credentials and contact information that enables the provider to be contacted including delivery or collection of electronic health messages. In
Scope: The Provider Director is responsible for maintaining the contact information about a healthcare provider along with their associated identifiers and credentials. It allows users to interrogate the directory to uniquely identify a provider and retrieve contacts details to enable communication such as electronic health messaging requiring digital authentication certificates. The Provider Directory should also support replication capabilities to enable federated systems to have local access to a set of provider details. Out of
Scope: The provider directory is not intended to be used for role-based access control or authorization, nor is it intended to maintain the kinds of services the provider is capable of performing. Description/Example/Use
Case: A Provider Directory should allow the addition of a new healthcare provider providing a master repository for maintaining contact and credential information. The Provider Directory will be used to uniquely identify the provider allowing their contact information to be used to communicate with the provider including electronic health messaging. Functional
Requirements/EHR Functional Model Mapping: Dependencies: Provider Directory would depend upon other services to perform authentication/authorization/ access control Functional
Capabilities: FindCandidates: RegisterProvider: GetProvider: UpdateProvider: CreateIdentifier: |
Provider Directory |
HealthConnect (Australia) U.S. Department of Defense (Health
Affairs) Canada Health Infoway Kaiser Permanente Kaiser-Permanente
Submission |
Purpose: The Provider Directory is an authoritative source for information on groups and individuals that provide healthcare services. This can be considered as an specialization of a generalized directory service, adding or supporting features and information that are applicable to healthcare providers but not to the general population. Note that the authoritativeness of any Directory may be relative: while a given set of applications may see Provider Directory A as an authoritative source for all information it provides (e.g., licensure), Provider Directory A may, in fact, obtain some of the information it supplies from other sources that it considers authoritative (e.g., a licensing authority). The scope of authority may be asserted by a Provider Directory within the contexts of defined working relationships. In
Scope: The Provider Directory exposes services to allow consumer applications to: · Retrieve provider information by identifier · Identify provider(s) based upon identification criteria · Identify candidate providers based upon non-identification criteria · Subscribe to provider update notification service · Request provider information update Out of
Scope: · Establish new provider. It is possible for a valid healthcare provider to be unknown to a given Provider Directory. A consumer application should be able to assert the existence of such a provider to the Provider Directory for subsequent validation by the Directory. However, this functionality is not in scope at this time. Description/Example/Use
Case: · Retrieve provider information by identifier o A laboratory application receives an order with a provider identifier that is unknown to the lab application. The lab application requests provider information from the Provider Directory in order to process the order. o (question: do we need to define limited vs. detailed response services, or can they just be criteria-driven versions of the one service?) · Identify provider(s) based upon identification criteria o
A patient requests that a pharmacy call
her dentist for a prescription related to an upcoming appointment. The patient can only describe the
dentist as Dr Smith, a woman, on o (it is possible that more than one provider may be returned by this service, the consumer application, or the human interface, will need to resolve the question of which is the "correct" provider.) · Identify candidate providers based upon non-identification criteria o
A physician needs to refer a patient to
a hematologist; however the patient requests that they be male, in
· Subscribe to provider update notification service o To meet business and regulatory requirements, a pharmacy application must maintain a minimum data content within the application. In order to ensure that this minimum data content is up-to-date, the pharmacy application registers itself with the Provider Directory using the Subscribe to provider update notification service. The pharmacy application maintains a listening service which receives information updates from the Provider Directory (for the providers known to the directory). · Request provider information update o A Visiting Nurse association periodically reviews the information provided by the Provider Directory for its members. Upon noting discrepancies between their membership information (as updated by the members) and that retrieved from the directory, the association sends requests to the Provider Directory to update and/or revalidate the directory's information from its sources. o (this may invoke both automated and manual updates/validation) Functional
Requirements/EHR Functional Model Mapping: (to be done) Dependencies: Provider Directory services would depend other
services to perform authentication/authorization/access control (is the
requestor allowed to request that service or view the associated
information). The "Identify provider(s) based upon identification criteria" service is dependent upon Identity Management services. It may be that the this Provider Directory service is the Identity Management services applied to the Provider Directory data. The "subscription to provider update notification
service" requires that the subscribing application expose an appropriate
"listener" service. Functional Capabilities: |
Consumer Directory |
HealthConnect (Australia) U.S. Department of Defense (Health
Affairs) Canada Health Infoway Kaiser Permanente |
Purpose: The Consumer Directory is an authoritative source for information individuals that utilize healthcare services. Note that the authoritativeness of any Directory may be relative: while a given set of applications may see Provider Directory A as an authoritative source for all information it provides (e.g., licensure), Provider Directory A may, in fact, obtain some of the information it supplies from other sources that it considers authoritative (e.g., a licensing authority). The scope of authority may be asserted by a Directory within the context(s) of defined working relationships. In
Scope: The Consumer Directory exposes services to allow consumer applications to: · Retrieve consumer information by identifier · Identify consumers(s) based upon identification criteria · Identify candidate consumers based upon non-identification criteria · Subscribe to consumer update notification service · Request consumer information update Out of
Scope: · Establish new consumer. It is possible for a valid healthcare consumer to be unknown to a given Consumer Directory. An application should be able to assert the existence of such a consumer to the Directory for subsequent validation by the Directory. However, this functionality is not in scope at this time. Description/Example/Use
Case: · Retrieve consumer information by identifier o A laboratory application receives an order with a consumer identifier that is unknown to the lab application. The lab application requests consumer information from the Consumer Directory in order to process the order. o (question: do we need to define limited vs. detailed response services, or can they just be criteria-driven versions of the one service?) · Identify consumer(s) based upon identification criteria o A pharmacy receives a verbal order from a dentist for a patient. The dentist has assorted demographic information (e.g., name, dob, address, phone) for the patient, but does not have the patient's healthcare identifier. No match is found in the pharmacy system for the demographics. Using these demographics as identification criteria, the pharmacy application queries the Consumer Directory to find the appropriate patient and healthcare identifier. o (it is possible that more than one consumer may be returned by this service, the pharmacy application, or the human interface, will need to resolve the question of which is the "correct" consumer.) · Identify candidate consumers based upon non-identification criteria o A County Health Service has received anecdotal reports suggesting that 18 – 25 year old males in a particular city are more likely to contract a particular infectious disease. To follow up on that assertion, the County Health Service needs to identify specific populations that, and surrounding, cities. These criteria are submitted to the Consumer Directory which returns candidate lists for the submitted criteria. · Subscribe to consumer update notification service o To meet business and regulatory requirements, a pharmacy application must maintain a minimum data content within the application. In order to ensure that this minimum data content is up-to-date, the pharmacy application registers itself with the Consumer Directory using the Subscribe to consumer update notification service. The pharmacy application maintains a listening service which receives information updates from the Consumer Directory (for the consumers known to the directory). · Request consumer information update o Subsequent to a dialysis encounter, staff at the dialysis center notes discrepancies on a patient's demographic information. After verifying the discrepancy with the patient, the staff enters the updated information into their patient management system. Since the patient management system assumes the Consumer Directory to be the authoritative source for this information, a Request consumer information update is sent. o (while sending the "known correct" information to the Directory may not be directly applied to the Directory data, it would assist Directory management, particularly if manual intervention became necessary.) o (this may invoke both automated and manual updates/validation) Functional
Requirements/EHR Functional Model Mapping: (to be done) Dependencies: Consumer Directory services would depend other
services to perform authentication/authorization/access control (is the
requestor allowed to request that service or view the associated
information). The "Identify consumer(s) based upon identification criteria" service is dependent upon Identity Management services. It may be that this Consumer Directory service is the Identity Management services applied to the Consumer Directory data. The "subscription to consumer update notification
service" requires that the subscribing application expose an appropriate
"listener" service. Question: Is there a distinction between this and the concept of a generalized directory service? What features or attributes of a healthcare consumer are not pertinent to the general population? Question:
does access to "consumer" information in health care need to define
two, or more, levels of access, or would that be a function of
authentication/authorization/access control? Functional Capabilities: |
Consumer Directory |
HL7
|
Service “Short” Name: Consumer Directory Alias: Master Patient Index, Identity Management, Person Identity Organizations with
Registered Interest: HL7
Purpose: A directory holding a healthcare consumer’s set of identifiers assigned by various authorities and demographic information, which can be used to establish the consumer’s identity. Additionally, the Consumer Directory maintains consumer contact details and other relevant administrative information including next of kin, insurance status, power of attorney and health record surrogates[HKF1] . In
Scope: The Consumer Director is responsible for maintaining the demographic and administrative information about a healthcare consumer along with their associated identifiers. It allows users to interrogate the directory to uniquely identify a consumer, verify consumer’s identity and retrieve consumer demographic and administrative details. The Consumer Directory should also support replication capabilities to enable federated systems to have local access to a set of consumer details. Out of
Scope: The Consumer Directory should not include consumer based health record access control list. Description/Example/Use
Case: A Consumer Directory should allow the addition of a new healthcare consumer for which an electronic health record has been created providing a master repository for maintaining demographic and administrative information separate from the EHR. The Consumer Directory will be used to uniquely identify the consumer allowing their unique identifier to be used to access their health record. Functional
Requirements/EHR Functional Model Mapping: Dependencies: Consumer Directory would depend upon other services to perform authentication/authorization/ access control Functional
Capabilities: FindCandidates: RegisterConsumer: GetConsumer: UpdateConsumer: LinkConsumer: CreateIdentifier: |
Workflow |
Ocean Informatics Veterans Health
Administration |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Health Record Access/Retrieval |
HealthConnect (Australia) U.S. Department of Defense (Health
Affairs) SerAPI Project (Finland) MedicAlert Foundation Veterans Health
Administration Ocean Informatics HL7
|
Service “Short” Name: Health Record Access/Retrieval Organizations with
Registered Interest: HL7
Purpose: A service for recording, retrieving, and manipulating information in a consumers’ electronic health record. In
Scope: The Health Record Access service is responsible for storing, retrieving, and manipulating healthcare consumers’ health record information. It allows users to submit and maintain health profile or event information and retrieving this information in a variety of views such as the original entries submitted or composed from multiple entries. Out of
Scope: The Health Record Access service is not intended to control the access to the health record. Description/Example/Use
Case: A Health Record Access service would be used to submit a summary of a hospital visit on or soon after a patient is discharged. The primary care provider could retrieve the details of the hospital visit along with follow up laboratory results the next time the healthcare consumer presents at his clinic. The PCP can retrieve the current medication list and which will be resubmit with the new prescriptions written along with other summarized information associated with the consultation. Functional
Requirements/EHR Functional Model Mapping: Dependencies: The Health Record Access service would depend upon another service to identify the individual or subject of an inquiry. The Health Record Access service would depend upon another service to locate the instance of the heath record access services for the kind of information required Health Record Access service would depend upon other services to perform authentication/authorization/ access control Functional
Capabilities: SubmitComposition: FindComposition: GetComposition: UpdateComposition: NullifyComposition: GetEntireRecord: GetRecordView: |
Role-Based Query Access |
Blue Cross/Blue Shield Canada Health Infoway |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Privacy/Security/Consent |
Canada Health Infoway MedicAlert Foundation NLM |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Record Location/Federation |
Canada Health Infoway IBM U.S. Department of Defense (Health
Affairs) SerAPI Project (Finland) Veterans Health
Administration Veterans Health Administration
Submission |
Purpose: The Record Locator Service (RLS) provides the ability to determine where information is located between or with health enterprises. It provides insight into metadata about information of interest, including items such as creator, category, source, size, format, language, dates, etc. In
Scope: The RLS is
responsible for the bookkeeping and ability to identify which server
instances contain categories of registered information about a
person. The Locator Service
maintains the following knowledge: ·
What categories of information (HL7
Templates) a given location knows about. ·
What categories of information (topics)
a given location wants to receive messages. ·
For which persons is information
stored.
Out of
Scope: It is
important to note that the RLS does not provide visibility into the
content of the information it is seeking, rather it is limited to
searching the form, structure, and metadata. For example, RLS cannot locate
only those results for a particular lab test that resulted as
positive. It could, however,
determine where laboratory records of that type exist for a particular
patient.
Description/Example/Use
Case: For instance,
the RLS may be used to determine if there are any nuclear images
for a particular person/patient role that have been made available in the
past 30 days. This
provides the ability to dynamically discover servers/services with
relevant content to a query or situation. Functional
Requirements/EHR Functional Model Mapping (still needs to be done) Dependencies: The RLS would depend upon another service to identify the individual or subject of an inquiry. The RLS would depend upon another service to perform the retrieval of record instances (e.g., RLS could return metadata but not data) RLS would depend upon other services to perform authentication/authorization/ access control Functional Capabilities: ð
FindLocations – Provides a list of systems/services in which
relevant data resides for a designated set of input criteria. The result of a GetLocations
invocation is a list of the locations containing data matching the query
criteria, and optionally the type of information available at those
locations. This would be
similar to the “treating facility list”. Examples
include: ð
Records of a certain
type by server instance (could be used for
Epidemiology) ð
Locations of all
records for a certain person ð
Locations where any
records exist for a person (based in part upon the OMG Health Information
Locator Service, RFP and [draft] initial
submission) |
Record Locator |
Submission from IBM |
Description The Records
Locator (RL) is the set of all health related data records associated with
a Person ID and the associated functions that can create / retrieve /
update / delete / search for the records. All actions on the RL must be
authorized for the actor and for the role in which the actor is performing
the action. Terms •
Location – a uniquely identifiable place where health information
regarding a person is stored. •
Location Entry – a single entry in the Records Locator that is
associated with a Person ID and can fully resolve the Location of the
health data. •
Location Attributes – the metadata associated with a Location Entry
that describes the health data stored at the
Location. •
Location ID – an identifier that is uniquely assigned to each
Location Entry Use
cases •
Create a Location o
Creates a new Location Entry in the RL. A Person ID and Location
Attributes must be provided and no collisions are allowed. A unique Location ID is
created. •
Retrieve Location o
Returns a particular Location Entry when provided a Location
ID. •
Update Location o
Changes the attributes associated with a Location ID. This should only be called when
health data records are moved to a new location. •
Retrieve a Person’s Locations o
Returns a list of all of the currently active health data records
along with the metadata associated with each
Location. •
Re-assign Location o
When provided a Location ID and a Person ID, this action will
associate the Location Entry with the specified person. This action can be used when a
duplicate Person record was created (i.e. a person who had a Person ID was
not identified and had a new Person ID created in the MPI and records were
associated with the new Person ID – this action would allow the records to
be merged under a single Person ID) •
Archive Location o
Allows the Location Entry associated with a Location ID to be
accessed in a less time sensitive manner than other Location Entries. Useful for maintaining information
for clinical research or for moving older, less useful Location Entries to
slower access media. •
Delete a Location o
Marks a Location Entry as being deleted. This action does not physically
delete the entry, but removes the Location from activity. Once deleted, the only two valid
actions on the Location Entry are Undelete or Purge. •
Undelete a Location o
Makes a previously ‘deleted’ Location Entry active. This action effectively undoes a
‘Delete a Location. •
Purge A Location o
Physically removes a Location Entry from the RL. This is an irrevocable action. |
Document Exchange |
HL7 Australia Submission |
Service “Short” Name: Document Exchange Organizations with
Registered Interest: HL7
Purpose: A service for managing the exchange of documents between healthcare providers. In
Scope: The Document Exchange service is responsible for securely storing and forwarding healthcare documents in transit between healthcare providers. It is intended to be a generic service to support a variety of healthcare documents which may need to be exchanged between providers. The service may notify (using insecure communication) the intended recipient (when known) that a document is awaiting collection with a link provided to allow direct access. Alternatively a document can be located using a search on metadata indexed at the time of the document being submitted to the document repository. This search may be based on unique identifiers encoded within bar codes or composite details such as healthcare consumer demographics and provider details. Out of
Scope: The Document Exchange service is not intended as a replacement of an electronic health Record or persistent document repository. Description/Example/Use
Case: A Document Exchange service is used to send an electronic pharmacy prescription to be held until healthcare consumer presents at the pharmacy where they have chosen to have their prescription filled. The Pharmacist scans the barcode encoding document identifier or searches for the prescription using demographics details take from the consumers’ photo identification. The prescription is identified in document registry that returns the actual location of the prescription, which is then retrieved, from the document repository. The prescription is filled as required and the document repository is updated to indicate the items that remain to be filled. Expired or filled prescriptions will be purged as required. Other use cases may include Referral, Pathology Orders and Diagnostic Investigation Results. Functional
Requirements/EHR Functional Model Mapping: Dependencies: The Document Exchange service would depend upon other services to perform authentication/authorization/ access control Functional
Capabilities: StoreDocument: FindDocument: GetDocument: RegisterDocument: NullifyDocument: UpdateDocument: |
MPI/Person Identity/Identity Management |
IBM Canada Health Infoway Inter-Mountain Healthcare NLM Submission from IBM |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: Description The MPI is a directory of Persons and the
associated functions that can create / retrieve / update / delete / search
Person Entries in the directory.
All actions on the MPI must be authorized for the actor and for the
role in which the actor is performing the action. Terms •
Person – an individual whose information is maintained in the MPI
directory within a Person Entry •
Person Entry – an single entry in the MPI directory corresponding
to a Person •
Person Attributes – the set of characteristics that, hopefully,
uniquely identify a Person •
Person ID – the unique identifier assigned to a Person Entry (see
also: Records Locator) Use cases •
Search for a Person Entry o
Provides an ordered list of Person Entries that match the given
criteria. The order of the
list is dependent on the weights assigned given Person
Entry •
Create a Person o
Creates a new Person Entry in the MPI directory. A minimum set of Person Entry
attributes must be present in order for the entry to be created. A unique Person ID is
assigned. •
Retrieve Person Attributes o
Returns all of the attributes for a Person Entry corresponding to
the Person ID provided by the caller. •
Update Person Attributes o
Changes the attributes associated with a Person Entry. This action permanently alters how
a Person Entry can be retrieved through a search. •
Archive a Person o
Moves the Person Entry to a non-active state while retaining all
other information about the Person.
Useful for maintaining information for clinical research while
removing the Person from active searches. This action should only be
performed when a Person has left the healthcare
system. •
Delete a Person o
Marks a Person Entry as being deleted. This action does not physically
delete the entry, but removes the Person from activity. Once deleted, the only two valid
actions on the Person Entry are Undelete or Purge. This action should not succeed if
there are records associated with the Person ID in the Records
Locator. •
Undelete a Person o
Makes a previously ‘deleted’ Person Entry active. This action effectively undoes a
‘Delete a Person’. •
Purge A Person o
Physically removes a Person Entry from the MPI directory. This is an irrevocable
action. |
Resource Scheduling |
(Keith Campbell) |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Terminology Services |
Mayo Clinic Department of Defense (Health
Affairs) Veterans Health
Administration SerAPI (Finland) MedicAlert Foundation Kaiser-Permanente InterMountain Health Kaiser-Permanente
Submission |
Purpose: Terminology Services provides definition and translation between, and within, term/concept sets. Available information includes metadata for the term/concept sets such as copyright, publication date, version/revision, structure, and languages supported. In
Scope: Terminology Services exposes the following services: · Translate code to concept. Supplied with a specific code and a designated terminology (e.g. code system), this service returns the associated concept information (e.g., definition, display string, comments, source attribution). If the terminology supports multiple languages, all language forms will be returned unless a specific language is specified in the request. · Retrieve child concept service. For hierarchically structured terminologies, this service returns any child concepts of the supplied code/concept. Depth of return (how many child generations) may be specified in the request. · Retrieve parent concept service. For hierarchically structured terminologies, this service returns the parent concept(s) of the supplied code/concept. Depth of return (how many parent generations) may be specified in the request. · Translate coded concept to alternate terminology (Simple). Supplied with a concept coded in a particular terminology, and an alternative terminology, this service returns all "mapped" concepts in the alternative terminology. Each returned concept will also include an indication if it uniquely maps back to the original concept (e.g., is the mapping bi-directional) ·
Out of
Scope: · Locate coded concept. Based upon supplied, non-coded, criteria (e.g., description), identify the related coded concept(s) in the specified terminology/concept sets. Description/Example/Use
Case: ·
Translate code to concept. Supplied with the coded concept of
"F" in code system HL70001, the service would return a description of
"Female", and an attribution of "Health Level 7, User-defined table 0001,
Administrative Sex" (and possibly other metadata, to be defined). · Retrieve child concept service. Supplied with the coded concept of "LIV" and code system 2.16.840.1.113883.5.41 with one generation requested, the service would return two terms: concept "PSN", display "Person" and concept "NLIV", display "non-person living subject" [additional data would include description, attribution, etc, not included here for brevity]. · Retrieve parent concept service. Supplied with the coded concept of "LIV" and code system 2.16.840.1.113883.5.41 with one generation requested, the service would return one term: concept "ENT", display "Entity" [additional data would include description, attribution, etc, not included here for brevity]. · Translate coded concept to alternate terminology (Simple). Supplied with the coded concept of "F" in code system HL70001, and a target terminology of SNOMED-CT the service would return concept " 248152002", description "Female" [and additional information or metadata not included here for brevity]. Functional
Requirements/EHR Functional Model Mapping: Dependencies: How are terminologies are identified? OIDs? Functional Capabilities: |
Service Locator |
Queensland Health |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Decision Support/Rule Interpretation |
Partners Healthcare Intermountain Health Ocean Informatics Mayo Clinic |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Record/Data Element Query |
Partners Health |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Action Invocation/Notification Service |
Partners Health |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Care Plan Management |
Blue Cross/Blue Shield |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Service Events/Encounters |
Canadian Institute for Health Informatics
(CIHI) |
Purpose: In
Scope: Out of
Scope: Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Functional Capabilities: |
Benefits Management |
Kaiser
Permanente Submission |
Purpose: Benefits Management provides In
Scope: Benefits management exposes the following services: · Retrieve benefit summary for patient. For a specified patient, the service returns basic benefits information (subscriber, payor, plan description, etc, including multiple accounts) for all benefits providers known to the service. The service request may include identification of the benefit provider to limit the returned information. · Retrieve benefit details for patient. For a specified patient, the service returns detailed benefits information (summary information as well as details on coverage, copayments and accumulated payments for all benefits services) for all benefits providers known to the service. The service request may include identification of the benefit provider and/or benefits services (e.g., Lab, Pharmacy, Dental) to limit the returned information. Out of
Scope: · Adjudicate service for patient. For a specified patient and health care service, the service returns information on whether the service would be a covered benefit. No implication of performance is included in the service request. · Pre-authorize service for patient. For a specific patient and health care service, the service returns either an authorization to perform the service, denial of coverage for the specified service, or a request for additional information needed to authorize the service. · Subscribe to benefit update notification for patient. For a specified patient and health care benefit provider, this service registers the requestor to receive notifications of changes to the benefit information for this patient under this service provider. The requesting application must expose a service to receive these updated. · Request validation of benefits for patient. This service provides a means for the health care provider (requestor) to initiate a review of the benefit information for a particular patient. For example, if a patient insists that their coverage include a specific service benefit, this service would allow the provider to request review of the patient's benefits generally or specifically to the service benefit in question. The health care provider would have to have business processes to deal with the immediate issue as t is not expected that this will be a fully automated service, but rather trigger some human intervention. Description/Example/Use
Case: Functional
Requirements/EHR Functional Model Mapping: Dependencies: Benefit management services depends on other
services to perform authentication/authorization/access control (is the
requestor allowed to request that service or view the associated
information). Benefit management services, as described here, presuppose proper, authoritative identification of the patient. This may not be the case and these services may utilize Identity Management services in order to uniquely identify the patient. Functional Capabilities: |
|
|
|
[HKF1]Is this part of an access control service
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]