I, too, have some trouble with a blurring of the line between registry and terminology.
A facility registry would contain symbolic code for a particular facility (identifier), plus domain specific data such as it’;s full name, location, type/level
of care ….
I would be comfortable with considering all the valid facility ID’s for, say Rwanda, to be held by the terminology server under some code set name “RWANDAN_FACILITY”.
But I would expect the FR to be the source of truth.
If TS wants a copy, then let it get (and then offer up to the HIE) that set of codes.
···
From: ohie-architecture@googlegroups.com [mailto:ohie-architecture@googlegroups.com]
On Behalf Of Carl Leitner
Sent: Tuesday, December 10, 2013 1:20 PM
To: Biondich, Paul G
Cc: ohie-architecture@googlegroups.com
Subject: Re: CSD and Termninologies
To provide a concrete definition/example for the case of CSD, what we are talking about are standardized data lists (or code sets (or terminologies)) that are being defined by the jurisdiction. In particular, looking at line 666 of the
CSD profile:
ftp://ftp.ihe.net/DocumentPublication/CurrentPublished/ITInfrastructure/IHE_ITI_Suppl_CSD.pdf
we have:
Implementing jurisdictions may mandate code sets for Organization Type, Service Type, Facility Type, Facility Status, Provider Type, Provider Status, Contact Point Type, Credential Type,
Specialization Code, and language code. Care Services Directory actors shall be configurable to use these code sets, where mandated.
I think what is key here are that these codes sets will need referenced and understood across more than one registry/system.
I am not sure that I would put a "provider’s given name” as a terminology — although the allowed components of a name (“firstname”, “surname”, “honorific” , etc.) may be.
Cheers.
-carl
On Dec 10, 2013, at 11:34 AM, Paul Biondich pbiondic@regenstrief.org wrote:
I think one thing perhaps missing from this discussion (at least for me) are clear definitions of what we mean by “terminology”.
I think most people can readily understand standard clinical termininologies and the traditional use of the terminology server as the host for these metadata.
I think we’re also starting to include more traditionally non-normalized data fields/attributes within registries in the definition of terminology. Things like a “facility type”, and a “provider’s given name”.
I don’t have any problem with adjusting the scope, but so that all can follow along with this thread, we should start by getting consensus on the scope of what we mean by “terminology”, as I fear most people are familiar with the former,
and less familiar with the latter, especially as it relates to the development of registries.
Thanks,
-Paul
On Mon, Dec 9, 2013 at 4:29 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Derek,
That sounds really promising. I’d be happy if started to align with using CTS2 for terminology exchange as we await the outcome of the project to align SVS with CTS2.
I guess a next topic for discussion would be what terminology should be hosted in the TS for OpenHIE. Clinical codes systems, administrative units and commonly used code systems seems to be appropriate to me.
Cheers,
Ryan
On Wed, Dec 4, 2013 at 7:23 PM, Derek Ritz derek.ritz@gmail.com wrote:
Hi all.
First off – thanks, Carl, for putting this on the radar and thanks, as well, for cutting together a quick support for SVS in the InfoMan. Very cool.
RE: the path forward, I think we should follow (closely!) the current work going on within HL7 to harmonize SVS within CTS2 (http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=946 ).
This looks like it is coming up for ballot soon and those of our OpenHIE community that get to cast votes (Regenstrief, HL7 Canada – my crew here at Infoway, and others in the HL7 “fold”) should get behind it. Basically, this ballot will harmonize the IHE,
HL7 and OMG work in this area and will, I think, clearly make CTS2 the “horse for the course” for all our TS messaging.
It will be an important step, then, for our TS community to embrace CTS2. Information at the CTS2 website (http://informatics.mayo.edu/cts2/index.php/Implementations ) talks
about RESTful json interfaces, XQuery interfaces, xml interfaces, etc. for CTS2 – so we should solidify that all of our TS interactions will use this as the interface. It also will give us a ready mechanism for the InfoMan to ensure interoperability by validating
that directory feeds are correctly referencing proper code sets for facility type, provider type, etc. Basically, if the TS is exposing a CTS2/SVS interface, then InfoMan can leverage that and do its checks of inbound directory feeds along with the other validity
tests that it already does. Likewise, directories (PR, FR, CR) can use the TS-exposed code sets to ensure that they are all singing from the same songsheet.
Interestingly, the InfoMan’s Service Directory is almost (in its simplest incarnation) looking like a code set directory. In this regard InfoMan is starting to potentially overlap with the TS… but let’s leave that issue for another day – after Connectathon.
What do others think? And as an aside – how ready is the rest of the team to start to do some over-the-net testing of CSD? Doing some testing is a big risk mitigator for us… (I’m just sayin’…).
Warmest regards,
Derek.
On Wednesday, December 4, 2013 9:04:48 AM UTC-5, Carl Leitner wrote:
Hi All,
Although we have had started the discussion of how we should manage terminology sets across registries, I do not believe we arrived at any conclusions. Two options were presented (CTS2 and SVS) for consideration. We recently received some more instructions
on CSD and the Connect-a-thon (see the copied e-mail below from Lynn Felhoher) which provides some motivation to integrate support for SVS within the CSD domain.
Lynn has provided use with a terminology set that we will need to use for testing. These terminologies include things like Facility Type, Facility Status, Provider Type, Service Type, Organization Type etc. This set was shared as a SVS document, which is defined
by this profile:
ftp://ftp.ihe.net/DocumentPublication/CurrentPublished/ITInfrastructure/IHE_ITI_Suppl_SVS_Rev2.1_TI_2010-08-10.pdf
At the moment, I have updated OpenInfoMan so that is is aware of these sets (needed for validation of Service Directories for the Connect-a-Thon):
http://csd.ihris.org:8984/CSD/SVS/initSampleSharedValueSet
Note however that the OpenInfoMan does not currently function as either of the two actors “Value Set Repository” or “Value Set Consumer” defined by the SVS profile. This is largely because we haven’t concluded our discussion on how we should share terminologies
between registries, both in terms of standards and software applications.
It would be relatively to add full support for both of the SVS actor’s to the OpenInfoMan. At least at first thought, it does seem natural for the OpenInfoMan to be a “Value Set Consumer.” However, I am a bit wary of scope creep for the OpenInfoMan “Value
Set Repository” actor. On the other hand, I am not aware of any open-source applications that play the role of the “Value Set Repository” as these are all the registered products:
http://product-registry.ihe.net/PR/pr/search.seam?actor=107&date=ANY|1386165271253|1386165271253
I’ll close with a few questions:
-
Does Apelon DTS plan to support the SVS profile?
-
Should OpenInfoMan conform to any of the actors from SVS?
-
Should we look also to support CTS2 within OpenInfoMan?
Cheers,
-carl
Dear CSD connectathon participants – Carl, Scott, Nico, Bob, Ryan
I would like to address two topics related to CSD connectathon testing. My target for this email is people who will be onsite in Chicago testing CSD from IntraHealth, InSTEDD, Woza Services, and Jembi Health Systems. If I have missed anyone in your organization,
please forward this note.
I ask that you take a few minutes to review the following…
(1) Connectathon code sets & test data
While developing the tests you will run at the Connectathon, I have prepared some codes and test data that will be used. Once the test data is complete, writing the tests will be a quick task for me.
I invite your review of the following. They are based on my interpretation of the CSD supplement. We may discover that my interpretation is differs from yours. In that case, you will help me discover my error, or perhaps we will discover an ambiguity in
the CSD spec.
Connectathon code sets - The CSD Supplement, Vol 1, section 35.1.1.1 says that the Directory shall be configurable to use code sets mandated by the juristiction. I have defined small code sets for the “Connectathon jurisdiction”. You will see them in the
attached zip file.
Connectathon test data - in the attached zip file, I have defined small Connectathon samples for organization, facilities, providers, services. Before I make the samples larger, I’d like to confirm with this group that the structure of what I have so far is
correct and does not contain any surprises.
CSD-Organizations-*.xml - contains the definition of one organization
CSD-Facilities-*.xml - contains the defintion of one facility offering three services from one organization
CSD-Providers-*.xml - contains the definition for 4 providers
CSD-Services-*.xml - here’s one where I need some guidance…
Vol 1, Sec 35.4.1 “Concepts” says this about a Service: Service – Each care service has a unique identifier. Examples include: surgical services, antenatal care services or primary care services. The combination of a Service offered at a Facility may have
specific attributes including contact person, hours of operation, etc.
Then, I look at Figure & Table Y.1-3 and surrounding text…
– It says, "…there is one FacilityService for each unique combination of Facility, Service and Organization
– In the table, the Unique Entity Identifier is labelled as a globally unique identifier for the organization. I suspect that is a typo
– In the end, I am stumped at how to encode the extension within the service. What is the “type” attribute used for? How is the oid for the extension different than the oid for the service?
(2) The connectathon schedule in January
I hope you’ve all found the schedule for the January connectathon. It is under the ‘Schedule’ link at the top of this page. You will find testing sessions from Monday Jan 27 through noon on Friday Jan 31. The connectathon has been a 5 day event to enable
organizations who test multiple profile to have time to complete their work. The connectathon policies mandate that all participants be in attendance the entire time; this is to ensure that test partners are available to each other all week. In very rare
cases, and CSD is one of them, participants are coming to the connectathon to test only one profile. It is highly unlikely that it will take all week for you to complete CSD testing. If you come with solid implementions, my guess is that this group will
be done within two or three days. Does anyone disagree? Based on your thoughts, we may be able be able to come to agreement among this group to focus CSD testing on 2 (or 3) days within the week, and give you back a couple of days. Note that the connectathon
organizers are asking you to register for your badge and hotel room by Dec 20, so I’d like to see if we can achieve consensus before Dec 13.
In conclusion, I am asking for your feedback both on the contents of the attachment and on the schedule. If this group would like me to host a short t-conn to discuss the Connectathon, let me know. I’d be happy to do that.
Thanks in advance for your review, and I welcome any other questions you may have.
Lynn Felhofer
IHE Technical Project Manager
<CSD_test_data.zip>
<CSD_connectathon_codes.zip>
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ohie-architecture+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
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.