FW: Interoperability Layer Orchestrated Transactions : Single Registry Services

Larry has provided a nice expansion of the Single Registry Services.

The terminology service probably has plenty of intricacies, depending on how complex the semantic network that it supports. And, as I mentioned before, the terminology service has different customers (programs,
not people).

The main thing is that the Single Registry Services will have quirks and details that will be ironed out by the subroups.

But, the business rule, should be:

Exposed Registries should have at least one easy to use interface to allow edge nodes to interactively disambiguate “items” in the real world.

(That is, it should be easy for a patient registration system at an edge node to do the queries it needs to find the correct Registration, combining the demographic details from the human patient standing there
with known demographic details contained in the registry.)

···

From: Lemmon, Larry
Sent: Wednesday, May 15, 2013 9:17 AM
To: Tucker, Mark
Cc: Khokhar, Shahid
Subject: Interoperability Layer Orchestrated Transactions

During the call yesterday you were given the task of coming up with what the HIM (Interoperability Layer) would need to orchestrate. Here is my straw man of what I think is needed. Feel free to wordsmith
or change at will.

Interoperability Layer Orchestrated Transactions

  1. Client Registry independent CRUD* transactions

a. Create new client record

b. Update client demographics

c. Retrieve single client or list of linked clients

d. Merge client with another existing client

e. Invalidate client leaving audit trail (no deletes)

  1. Provider Registry independent CRUD transactions

a. Create new provider record

b. Update provider information

c. Retrieve provider information

d. Merge provider with another existing provider

e. Invalidate provider leaving audit trail (no deletes)

  1. Facility Registry independent CRUD transactions

a. Create new facility record

b. Update facility information

c. Retrieve facility information

d. Merge facility with another existing facility

e. Invalidate facility leaving audit trail (no deletes)

  1. Terminology Service independent CRUD transactions

a. Create new concept record

b. Update concept information

c. Create new coding system (LOINC, SNOMED-CT, ICD9, RXNORM, etc)

d. Update coding system elements (monthly updates)

e. Retrieve single concept or panel of concepts

f. Flag concept as being superseded (no deletes)

g. Create “labeled arc” between two terms (assuming there is some sort of semantic tree.)

*From Wikipedia:

CRUD = Create, Read (Retrieve), Update, and Delete

the four basic functions of persistent storage

Thanks, this is helpful. I think that we will have to work with / look to other OpenHIE communities to ensure each tool has a interface that gives us these sort of functions. This is a good generalization of the sort of transactions we envisage flowing though the interoperability layer.

Cheers,

Ryan

···

On Wed, May 15, 2013 at 3:31 PM, Tucker, Mark mtucker2@regenstrief.org wrote:

Larry has provided a nice expansion of the Single Registry Services.

The terminology service probably has plenty of intricacies, depending on how complex the semantic network that it supports. And, as I mentioned before, the terminology service has different customers (programs,
not people).

The main thing is that the Single Registry Services will have quirks and details that will be ironed out by the subroups.

But, the business rule, should be:

            Exposed Registries should have at least one easy to use interface to allow edge nodes to interactively disambiguate “items” in the real world.

(That is, it should be easy for a patient registration system at an edge node to do the queries it needs to find the correct Registration, combining the demographic details from the human patient standing there
with known demographic details contained in the registry.)

From: Lemmon, Larry
Sent: Wednesday, May 15, 2013 9:17 AM
To: Tucker, Mark
Cc: Khokhar, Shahid
Subject: Interoperability Layer Orchestrated Transactions

During the call yesterday you were given the task of coming up with what the HIM (Interoperability Layer) would need to orchestrate. Here is my straw man of what I think is needed. Feel free to wordsmith
or change at will.

Interoperability Layer Orchestrated Transactions

  1. Client Registry independent CRUD* transactions
a. Create new client record
b. Update client demographics
c. Retrieve single client or list of linked clients
d. Merge client with another existing client
e. Invalidate client leaving audit trail (no deletes)
  1. Provider Registry independent CRUD transactions
a. Create new provider record
b. Update provider information
c. Retrieve provider information
d. Merge provider with another existing provider
e. Invalidate provider leaving audit trail (no deletes)
  1. Facility Registry independent CRUD transactions
a. Create new facility record
b. Update facility information
c. Retrieve facility information
d. Merge facility with another existing facility
e. Invalidate facility leaving audit trail (no deletes)
  1. Terminology Service independent CRUD transactions
a. Create new concept record
b. Update concept information
c. Create new coding system (LOINC, SNOMED-CT, ICD9, RXNORM, etc)
d. Update coding system elements (monthly updates)
e. Retrieve single concept or panel of concepts
f. Flag concept as being superseded (no deletes)
       g.   Create “labeled arc” between two terms (assuming there is some sort of semantic tree.)

*From Wikipedia:

CRUD = Create, Read (Retrieve), Update, and Delete

      the four basic functions of persistent storage

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org