← Prev in month
← Prev in thread
OMG HL7 "Integrated" Service Descriptions Document
Title: Message
From:
Rubin, Ken (EDS)
[SMTP:]
To:
;
Cc:
Subject:
"Integrated" Service Descriptions
Document
Sent:
2/16/05 12:46
AM
Importance:
Normal
All:
Okay, here is what we have in to date. Thanks to
Virinder, Heath,
Scott, Alan for providing
input. I have promises that other
descriptions are on the way, but at least this gives us a starting
point
to compare and contrast some of what people
are thinking regarding these
services.
Note that in some cases we have competing submissions that
will need to
be reconciled. I made no
attempt to do so. We need to discuss an
approach for this on our next call.
I expect that we will have a few more descriptions trickle
in over the
coming days, and I'll get them
integrated and posted.
We also have what appears to be positive movement on the
collaborative
tooling front, and hope to be able
to provide more details soon.
- 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
Australia
Submission
Service “Short” Name:
Provider
Directory
Organizations with
Registered Interest:
HL7
Australia,
U.S. Department of Defense
(Health Affairs),
Canada
Health Infoway, Kaiser Permanente
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 Western
Ave in Los
Angeles.
Using these identification criteria, the pharmacy application
queries the Provider Directory to find the appropriate dentist to
contact.
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
Ventura
County, in a solo practice, and
at least 40 years old. Via
the physician's office practice application, the Provider Directory is
queried and a list of candidate providers is presented for
selection.
·
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
Australia
Submission
Service “Short” Name:
Consumer
Directory
Alias:
Master Patient
Index, Identity Management, Person Identity
Organizations with
Registered Interest:
HL7
Australia,
U.S. Department of Defense
(Health Affairs),
Canada
Health Infoway, Kaiser Permanente
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
Australia
Submission
Service “Short” Name:
Health Record
Access/Retrieval
Organizations with
Registered Interest:
HL7
Australia,
U.S. Department of Defense
(Health Affairs), SerAPI Project
(Finland),
MedicAlert Foundation, Veterans Health Administration, Ocean
Informatics
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
Australia
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).
Supplied with the coded
concept of "LIV" and code system 2.16.840.1.113883.5.41, the service would
return a display string of "Living Subject", a description of " Anything
that essentially has the property of life, independent of current state (a
dead human corpse is still essentially a living subject)", an attribution
of "Health Level 7", a terminology description of "EntityClass" (and
possibly other metaday, 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
Duke University
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
← Prev in month
← Prev in thread