ITI-115 Needs to Provide Discovery Mechanisms

[adityabansod]

We (https://github.com/lumahealthhq/) are implementers of the Argonaut Scheduling IG and looking forward to the evolution of the spec here. One of the things the draft does not address is how to generate the parameters required for transaction ITI-115.

In practice, as an implementer of these specifications, we've found that finding the localized data (2:3.115.4.1.3 Expected Actions) for Pracitionar and Location to be well understood, but specs fall short in providing a way to query for Reason/ServiceCategory/ServiceType.

In every EHR we have implemented against (MEDITECH, Epic, Cerner, etc) the "visit type" / "appointment type" concept is always a localized concept and never properly maps to any codeable value -- i.e. most hospitals have 20 different types of NEW PATIENT types and they are unmappable to SNOMED or anything else.

Without a proper discovery API REQUIRED in the spec, all implementers end up having to side load a dictionary, receive files via SFTP, or place in site-specific configurations the values for a visit type.

We'd suggest making this required as part of the specification in order to simplify the implementation for all Scheduling Clients and also for the teams that support Scheduling Servers.

[vassilpeytchev]

As presented in the issue description, the determination of visit type / service category / healthcare service is highly localized. This applies not only to the coded values, but also to any mechanisms for discovery. An international standard that strives for universal applicability will have a hard time standardizing this domain as part of the scheduling workflow, We think that keeping this part of the scheduling process out of scope, and recommending the mCSD profile as a discovery mechanism for the HealthcareService is the appropriate approach at this time, See https://build.fhir.org/ig/IHE/ITI.Scheduling/volume-1.html#15561-mcsd---mobile-care-services-discovery