Stream: implementers
Topic: Potential use of DocumentReference
Viktor Jernelöv (Nov 28 2019 at 10:00):
We're looking at how to translate the Swedish national architectural concepts realised by the current interoperability framework to a FHIR based implementation, and have struggled a bit with how we should handle our information index.
In Sweden today we have a central, national information index (we call it EngagementIndex) in our national service platform. The national service platform is built in accordance to a SOA architecture that enables a federation of regional platforms to communicate with each other. The EngagementIndex can contain a variety of metadata about the actual information, but particularly interesting to us at this point are the following elements:
*Registered Resident Identification (the patient ID)
*Categorization (information category of the data indexed. In our FHIR implementation we see this as translatable to FHIR profiles)
*Logical Address (a logical address to the information source, i.e the system)
*Data Controller (a logical identifier of the agent responsible for the data. Strictly controlled by a specific Swedish law handling information ownership and responsibilties associated with that ownership)
*Source System (a logical reference to the system where the index post was generated. Can be a different from the system where the data exists)
We're looking at the DocumentReference resource to be the carrier of this data in our FHIR implementation, but we're struggling to find a good match between our current index model and what DocumentReference offers:
*The patient ID maps to DocumentReference.subject of type Patient
*Categorization as the FHIR Profile matches conceptually against DocumentReference.category, but the question here is if the CodeableConcept datatype is a good fit for canonical URLs referencing specific profiles?
*Logical Address is more difficult, since the DocumentReference.content.url references a specific URL where the information can be retrieved. What we're looking for is a logical address that can be resolved to a FHIR Server's baseURL (and thus not the URL itself to enable loose coupling).
*Data Controller is in a way possible to represent using the DocumentReference.custodian, but the description of what the custodian is only somewhat matches the concept of Data Controller derived from the Swedish law
*Source System has the same problem as Logical Address
This puts us in a predicament. We CAN of course profile the DocumentReference and write an ImplementationGuide for our use of DocumentReference, but the consequences will be that we create our own Swedish flavor of the DocumentReference resourse that is in fact not a natural "child" of the DocumentReference resource as defined in the standard.
What does the community think? Are we wrong in profiling the DocumentReference resourse according to our needs? How do we bridge the differences between our needs and what DocumentReference allows us to express?
Vadim Peretokin (Nov 28 2019 at 10:13):
It sounds like you would like to store administrative information about the patient?
Viktor Jernelöv (Nov 28 2019 at 10:17):
Well, it's more information about what type of data exists about a certain patient and where (logically) it can be found and who "owns" it
Grahame Grieve (Nov 28 2019 at 10:21):
if the CodeableConcept datatype is a good fit for canonical URLs pointing to specific profiles
Maybe. The system URI urn:ietf:rfc:3986 exists for this purpose. But profile... that's not really category? it kind of depends how it's defined...
Grahame Grieve (Nov 28 2019 at 10:22):
What we're looking for is a logical address that can be resolved to a FHIR Server's baseURL (and thus not the URL itself to enable loose coupling).
I'm just thinking that through... not sure how it works... when you query, the server isn't resolved?
Grahame Grieve (Nov 28 2019 at 10:24):
note this, though, in the definition of Attachment.url:
Urls may be relative references
Grahame Grieve (Nov 28 2019 at 10:24):
what's the difference in definition of the data controller?
Grahame Grieve (Nov 28 2019 at 10:25):
Are we wrong in profiling the DocumentReference resourse according to our needs?
No. I think you should be looking at DocumentReference
René Spronk (Nov 28 2019 at 10:55):
DocumentReference.category, why would those be URLs ? DocumentReference.format is where the URLs of the profiles should be listed [although that data element doesn't repeat right now] , with content.attachment.url the address (the LogicalAddress). This need not be the url of a document, in the case of on-demand documents the url is already a symbolic url for a document - your Logicaladdress is the closest thing you have to the answer 'where' can this be found. Source System would be either on the Provenance resoirce (for the DocumentReference) or in DocumentManifest. Data controller soudns like custodian to me, but if there's a significant difference in definition of the term under Swedish law you'd be looking at an extension.
Viktor Jernelöv (Nov 28 2019 at 12:26):
if the CodeableConcept datatype is a good fit for canonical URLs pointing to specific profiles
Maybe. The system URI
urn:ietf:rfc:3986exists for this purpose. But profile... that's not really category? it kind of depends how it's defined...
In Sweden today we have various codes representing business object types (lab results, diagnoses, referral, care documentation etc) that are used to define and control access to information. These codes are mapped to the different web service contracts we use today, and this information is used by our aggregating services as part of an "endpoint discovery" process to resolve which URLs to send the original request to. These codes are represented in the Categorization element in our current index information model. Our thinking is that the "categorization", as used in a Swedish context", would translate pretty well to the concept of Profiles in FHIR.
We want to keep using these categorization codes since they're part of our existing solution so we're trying to figure out how to fit our current needs into what FHIR offers. The description of DocumentReference.category hinted that this would be potential candidate for this requirement.
Worth adding is that we intend to use the REST paradigm and not the Document paradigm. We're also trying to replace or complement parts of our existing infrastructure with FHIR based patterns and components in a modular fashion.
Viktor Jernelöv (Nov 28 2019 at 12:32):
What we're looking for is a logical address that can be resolved to a FHIR Server's baseURL (and thus not the URL itself to enable loose coupling).
I'm just thinking that through... not sure how it works... when you query, the server isn't resolved?
So this is a somewhat simplified description of what happens:
*A Consumer queries an aggregating service. The aggregating service supports retrieval of one of these business objects referenced in my previous response.
*Request parameters are Patient ID + some other optional stuff
*The aggregating service checks the EngagementIndex to see where (logically) there is information related to the patient. Since the aggregating service itself has a categorization code implied to it, it knows which posts to look for
*The aggregating service then uses another service, an address lookup feature, to resolve the physical address of the system referenced to by the LogicalAddress element in the index post
*The aggregating service makes the request(s) to the relevant systems and returns the data to the Consumer
René Spronk (Nov 28 2019 at 12:35):
The issue with 'record location services' is that the amount of metadata wildly differs between implementations. This could be fairly minimal (as in the Dutch national infrastructure: basically (Endpoint, patient id) tuples), or fairly rich in nature (as in the case of IHE XDS metadata). XDS is for documents, but some RLS services aren't limited to documents. As such you use case (when generalized) is more about RLS and Federated use of FHIR, and yes, DocumentReference is the closest thing we have but its design is optimized for use with IHE XDS architectures.
René Spronk (Nov 28 2019 at 12:37):
The aggregation process you mention looks exactly the same as one used by the Dutch LSP project (theirs is not based on FHIR [right now], but the same principles apply). @Alexander Henket
Viktor Jernelöv (Nov 28 2019 at 12:44):
what's the difference in definition of the data controller?
Custodian is defined in the specification as:
Identifies the organization or group who is responsible for ongoing maintenance of and access to the document.
and comment says
Identifies the logical organization (software system, vendor, or department) to go to find the current version, where to report issues, etc. This is different from the physical location (URL, disk drive, or server) of the document, which is the technical location of the document, which host may be delegated to the management of some other organization.
This is different from the legal concept behind Data Controller ("Vårdgivare" in Swedish), which is on a much higher level than what custodian seems to indicate. Custodian to me sounds like the organization or group of people who actually work with maintaining the data referenced by DocumentReference, whereas the Data Controller more is used to derive who gets to access what data under what circumstances, and to some extent I guess, who should be sent to jail if things go south.
It's not a perfect match at all, but one could argue of course that custodian is close enough to warrant its use. I'm personally on the fence here but if the community thinks it's a valid case then I won't object that much.
Viktor Jernelöv (Nov 28 2019 at 13:00):
As such you use case (when generalized) is more about RLS and Federated use of FHIR, and yes, DocumentReference is the closest thing we have but its design is optimized for use with IHE XDS architectures.
Yes, that's pretty spot on I believe. However, we're hoping for some form of guidance from the community since we COULD implement a non-FHIR resource for this and push that into our otherwise FHIR based framework, but that just feels icky. On the other hand, how much of your own flavor can you/are you allowed to add to existing resources and still be able to achieve some form of interoperability? I realize there's no easy answer to that question.
René Spronk (Nov 28 2019 at 13:01):
Controller: more in the sense of a legal responsability, e.g. a GDPR Controller = ‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;
René Spronk (Nov 28 2019 at 13:03):
The thing is: DocumentReference was created (well: reverse engineered, if you want) based on IHE XDS requirements. NHS Digital in the UK are also working on a FHIR based RLS. As such we (as the FHIR community) may have to step back and focus on RLS requirements [in general], in the realisation that IHE XDS represents just one RLS scenario (rich metadata, documents as the record format).
René Spronk (Nov 28 2019 at 13:05):
This may very well lead to a new resource, or to a generalization of what the current DocumentReference does. Your use case is not unique, so I'd urge you not to go it alone :-)
Viktor Jernelöv (Nov 28 2019 at 13:05):
Controller: more in the sense of a legal responsability, e.g. a GDPR Controller = ‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;
Yes, this seems closer to home than the custodian definition. I've been trying to get our legal people to provide us with English translations of certain Swedish key legislative texts, but so far to no avail. It's very difficult to translate these concepts for a layman such as myself.
René Spronk (Nov 28 2019 at 13:06):
That was a verbatim copy of the GDPR definition, by the way.
René Spronk (Nov 28 2019 at 13:09):
@Tessa May , what is England planning to use as a resource at the core of its RLS ?
Viktor Jernelöv (Nov 28 2019 at 13:29):
with content.attachment.url the address (the LogicalAddress).
This doesn't seem to work with the specification though? Our LogicalAddresses are basically text strings (SE1562124AFRI-14LP) and the content.attachment.url is a url. We need a uri to represent this (as Grahame pointed out), but that seems difficult to find
Tessa May (Nov 28 2019 at 15:31):
For England's RLS we have profiled the STU3 DocumentReference resource: https://fhir.nhs.uk/STU3/StructureDefinition/NRL-DocumentReference-1
Further information on how we are using the metadata can be found here on our specification: https://developer.nhs.uk/apis/nrl/explore_reference.html
We have tried to find a balance between having a lean data model to be generic across a range of use cases and also matching the minimum data set that is widely used in IHE XDS implementations in England, which is much richer as René has mentioned.
Tessa May (Nov 28 2019 at 15:36):
What we're looking for is a logical address that can be resolved to a FHIR Server's baseURL (and thus not the URL itself to enable loose coupling).
I'm just thinking that through... not sure how it works... when you query, the server isn't resolved?
So this is a somewhat simplified description of what happens:
*A Consumer queries an aggregating service. The aggregating service supports retrieval of one of these business objects referenced in my previous response.
*Request parameters are Patient ID + some other optional stuff
*The aggregating service checks the EngagementIndex to see where (logically) there is information related to the patient. Since the aggregating service itself has a categorization code implied to it, it knows which posts to look for
*The aggregating service then uses another service, an address lookup feature, to resolve the physical address of the system referenced to by the LogicalAddress element in the index post
*The aggregating service makes the request(s) to the relevant systems and returns the data to the Consumer
This sounds quite similar to our service, except we have separated into two main actions for a Consumer: retrieving the DocumentReferences and retrieving the referenced data. Our RLS is just an index of records/documents and the Consumer uses the DocumentReference resource metadata to retrieve the data directly from the Provider system.
Tessa May (Nov 28 2019 at 15:48):
if the CodeableConcept datatype is a good fit for canonical URLs pointing to specific profiles
Maybe. The system URI
urn:ietf:rfc:3986exists for this purpose. But profile... that's not really category? it kind of depends how it's defined...In Sweden today we have various codes representing business object types (lab results, diagnoses, referral, care documentation etc) that are used to define and control access to information. These codes are mapped to the different web service contracts we use today, and this information is used by our aggregating services as part of an "endpoint discovery" process to resolve which URLs to send the original request to. These codes are represented in the Categorization element in our current index information model. Our thinking is that the "categorization", as used in a Swedish context", would translate pretty well to the concept of Profiles in FHIR.
We want to keep using these categorization codes since they're part of our existing solution so we're trying to figure out how to fit our current needs into what FHIR offers. The description of DocumentReference.category hinted that this would be potential candidate for this requirement.
Worth adding is that we intend to use the REST paradigm and not the Document paradigm. We're also trying to replace or complement parts of our existing infrastructure with FHIR based patterns and components in a modular fashion.
We are currently referencing specific documents or resources (using the DocumentReference.content.format element to describe the profile), but we are in discussions about how we will manage referencing a FHIR server's base URL as well. One thing we have considered for listing the supported profiles is referencing the CapabilityStatement for the FHIR server in the format element. It would be helpful to get input on this though if anyone has other thoughts/suggestions.
@Viktor Jernelöv , is the Swedish code list for 'categorisation' available? We are in the process of defining a set of categories for our RLS and it would be helpful to see what is used elsewhere.
Grahame Grieve (Nov 28 2019 at 15:59):
This doesn't seem to work with the specification though? Our LogicalAddresses are basically text strings (SE1562124AFRI-14LP) and the content.attachment.url is a url. We need a uri to represent this (as Grahame pointed out), but that seems difficult to find
The logical address looks like a relative URL to me?
Grahame Grieve (Nov 28 2019 at 16:00):
I think your Data Controller is the custodian. It's probably a question for IHE XDS people as well, but we could clarify the language in a future version
Rolf Rönnback (Nov 28 2019 at 16:39):
The logical address is NOT a relative URL. We use the concept of logical address to achieve a loose coupling between the identity of a certain business unit (e.g. a certain care provider) and the technical address (e.g. an URL) to the system publishing its information. The logical address is therefor just a text string.
Grahame Grieve (Nov 28 2019 at 16:44):
what happens with it?
John Moehrke (Nov 28 2019 at 19:21):
as the one that normally defends the DocumentReference... I think what is being discussed is a new Resource that is not yet modeled in FHIR. It is as Rene has mentioned a resource that is specific to record location in a federated environment. The DocumentReference does fill this role today in XDS and XCA environments. And some have taken advantage of the more open definition of 'document' as defined in DocumentReference. In that way the attachment.url points at something that is a bundle of FHIR Resources, mostly something that is automatically generated upon-demand (more like an operation in FHIR terms).
John Moehrke (Nov 28 2019 at 19:21):
What is not clear is how this functionality need overlaps Patient... as it is also a function of finding all identities of Patient that are the same human....
John Moehrke (Nov 28 2019 at 19:22):
So I see it as a new resource (or is it an operation) that overlaps the functionality of Patient cross-reference (IHE XCPD) and an index of the kind of data found at each location (IHE XCA ++).
John Moehrke (Nov 28 2019 at 19:24):
This lack of an obvious solution is why IHE has chosen to NOT start a XCA-on-FHIR project (although I have started a XDS equivalent on full FHIR stack-- MHDS). I would like to see these cross-community of interest come together and see what falls out...
John Moehrke (Nov 28 2019 at 19:26):
I think your Data Controller is the custodian. It's probably a question for IHE XDS people as well, but we could clarify the language in a future version
Not really an XDS question as the custodian is not an element in XDS... The custodian in an XDS environment would tend to be more identified by the RepositoryUniqueId, which has not independent map in DocumentReference...
René Spronk (Nov 29 2019 at 07:46):
@John Moehrke Actually for countries like the UK, Sweden or the Netherlands the whole "finding all identities of Patient that are the same human" is mostly a no brainer, there being some sort of national patient/citizen ID. As such we shouldn't mix that particular issue (the US notably suffers from a lack of such an ID) with the requirements for a RLS.
IHE XDS et.al. also assume a lack of solid identifiers for patients and providers, which (if mapped to FHIR) leads to contained resources for authors and patients. That's a fairly sub optimal way of doing things if one already has national registries for patient and providers. Yes, we try and cater for all these circumstances, but sometimes we should start with the common use case, not the lowest common denominator use case. (end of rant)
René Spronk (Nov 29 2019 at 07:48):
I agree that this may be a new resource, where ideally the current DocumentReference functionality is a "profile" on that new resource.
Jose Costa Teixeira (Nov 29 2019 at 07:55):
Agree, but I must add the not-so-common issue that we do not have a EU citizen ID
Viktor Jernelöv (Nov 29 2019 at 08:49):
what happens with it?
I'm not sure if these sequence diagrams help @Grahame Grieve ? We made them to have a base to start from in our FHIR work. Also @Tessa May , do they seem similar to what you have in mind?
https://www.lucidchart.com/invitations/accept/737290b0-736a-43c8-908a-2fed188fcc3d
Grahame Grieve (Nov 29 2019 at 11:59):
well, I think I'd benefit from some explanation...
Grahame Grieve (Nov 29 2019 at 12:00):
or hint for where I should start
Viktor Jernelöv (Nov 29 2019 at 14:33):
Perhaps we need more precise questions so we can help bridging the gap of understanding here. I don't know at where to start explaining besides what I've tried in this thread already. What am I not seeing?
René Spronk (Nov 29 2019 at 15:17):
Would the use of the Endpoint resource be suitable in your context ? What other changes would you propose in order to support your RLS use case ? In general I'd say we need to be able convey metadata of 'a category of information' and not just one single item of information (i.e. one document, one binary or one resource)
Umberto Cappellini (Nov 29 2019 at 16:14):
Isn't DocumentReference.masterIdentifier.system matching your requirement for Logical Address ?
Grahame Grieve (Nov 29 2019 at 17:42):
when I look at the diagram, where does use of the logical identifier appear?
Umberto Cappellini (Nov 29 2019 at 20:02):
I guess it's on 7.2, where they provide the aforementioned Logical Address to receive back the Physical address of the FHIR server.
I was thinking to use DocumentReference.masterIdentifier.system as:
DocumentReference.masterIdentifier => Document identifier as assigned by the source of the document.
masterIdentifier.system => a URI establishing the namespace for the value.
Which looks to fit the requirement "a logical address to the information source, i.e the system". The identifier may have no value as well, if not known.
My 2c.
Grahame Grieve (Nov 29 2019 at 20:05):
well, you could use masteidentifier, but there remains the question of what to put in content.attachment
Grahame Grieve (Nov 29 2019 at 20:07):
so.. you get the document reference from one server that knows about the content sources, but you ask another server for the actual address the content is found at once you have the document identifier?
Grahame Grieve (Nov 29 2019 at 20:07):
@John Moehrke does XDS have a workflow like this? if it does, how does it work?
Umberto Cappellini (Nov 29 2019 at 20:24):
It's a model similar to XCA. Each document is identified by a homeCommunityID + documentID, and the homeCommunityID is resolved to a physical address through a lookup to a directory.
René Spronk (Nov 30 2019 at 07:50):
Endpoint URLs will change over time, whereas the symbolic id of the application is less likely to do so. And yes, communityId is a similar concept. DocumentReference.masterIdentifier.system is not, as it is the 'system' for an identifier, and not in and of itself an 'identifier of an application'.
My proposal would be to add a reference to Endpoint in DocumentReference, with a constraint rule that says: either the DocRef is about 1 single document, and there should be an attachment, or the DocRef is about a class/category of [multiple] documents which can be found at the Endpoint.
Kevin Mayfield (Nov 30 2019 at 09:14):
When I looked at RLS, it catered for Documents but not for all questions like which Organisation has records for this patient. I couldn't get a clear steer on this, thoughts were to work it out from master registry of Patient (and infer by identifiers), Encounter/Episodes (implied) and Documents (implied).
Once I had the Organisation I would need to look up the Endpoint which would point me to their main FHIR Server (where I would get security info).
John Moehrke (Nov 30 2019 at 16:04):
Seems there are at least two very different models being discussed here. One is trying to figure out how to make DocumentReference work for an pre-determined three layer architecture. In this case, I push back and ask why on the highly connected internet is this needed? If one can get a fresh DocumentReference resource, why is it felt that the URL found in that DocumentReference can't be a fully qualified http GET resource/docment? In the IHE MHD world, this is what is presumed; that the service that is giving you DocumentReference resources will put a fully qualified URL into the attachment.url. I fully understand the XCA architecture, I just don't see why it is needing to be re-invented in FHIR, when FHIR is based on http REST, and has security models from OAuth.
John Moehrke (Nov 30 2019 at 16:07):
The second model I am seeing is a top-down discovery model. First discover the Patient identity (and if there is only one, this step is small), then discover all the Locations with data on that Patient Identity (where Location may be personal health record, or may be healthcare Organization managed, etc); then discover the data at that Location (endpoint(s))... I tend to think that this model is more similar to a model one would design given a FHIR model. And this model would work fine with the IHE Document Sharing exchanges, while also working better with FHIR resources.
John Moehrke (Nov 30 2019 at 16:11):
so.. you get the document reference from one server that knows about the content sources, but you ask another server for the actual address the content is found at once you have the document identifier?
@Grahame Grieve one perspective on XCA would describe it this way. One asks for the DocuemntEntry, and within the DocumentEntry returned are the tripplet of homeCommunityID, RepositoryID, and Document ID. Each are ID (with accompaning metadata you use to pick which one is of interest). But if you want to pull the document you need to ask your XCA federation to track down the Document ID, at the Repository ID, at the homeCommunityID. And the federation (XCA) tracks that down (or fails). Point is that you always ask your local entry point to the XCA federation for everything, and it is responsible for knowing where each homeCommunity is, and the entry point to that homeCommunity is responsible for knowing where each RepositoryID is... Hence a Federation.
John Moehrke (Nov 30 2019 at 16:15):
Federations are very helpful... which is a strength of XCA... but I think the "second model" above is potentially a better design for a federation that is fundimentally FHIR based. It still requires a federation, just focuses the federation on that intermediate function between (find the patient identity), and (retrieve specific data). That is to find all the Endpoint that have data. Where one can discover Organization from Endpoint, and one can look up CapabilityStatement at that Endpoint.
Grahame Grieve (Nov 30 2019 at 18:07):
I don't think there's a FHIR-ish way to say 'for this patient, what end-points have data' but it also sounds different to what the architecture is here
René Spronk (Dec 01 2019 at 08:22):
@John Moehrke To me the second model does seem to be the most fitting one. "Location" would need a good definition, for it could be all sorts of things, one person's Location would be anothers Endpoint.
John Moehrke (Dec 02 2019 at 15:04):
Yes, that is why I think that there is a new Resource type. It is not DocumentReference, and it is not Patient. It certainly should leverage CapabilityStatement, and it should not take the place of normal query of a given endpoint. Not clear what kind of a service this is, it doesn't feel purely REST. Today these services get an HL7 v2 ADT feed that is used to learn centerally where data might be for any given patient. Is this the right model in FHIR? Might this service be simply a routing hub that starts inefficient for any given patient (broadcast), but based on returned results becomes more refined for that patient?
But without this kind of a record location service, clients are forced to probe all possible FHIR endpoints (or the user must pick and choose) -- this is not scale... and even knowing all possible endpoints is not clear how that is done...
And the system must be secure and privacy protecting...
Viktor Jernelöv (Dec 02 2019 at 16:07):
I don't think there's a FHIR-ish way to say 'for this patient, what end-points have data' but it also sounds different to what the architecture is here
The need for us in Sweden is to find a FHIR-ish way of saying 'for this patient, what end-points have data of this kind', given that we use the same principles that laid grounds for our current SOA architecture, which I suppose could be up for discussion. At least that's the problem we try to solve now using FHIR.
Viktor Jernelöv (Dec 02 2019 at 16:08):
I guess it's on 7.2, where they provide the aforementioned Logical Address to receive back the Physical address of the FHIR server.
This is correct.
Viktor Jernelöv (Dec 02 2019 at 16:17):
Seems there are at least two very different models being discussed here. One is trying to figure out how to make DocumentReference work for an pre-determined three layer architecture. In this case, I push back and ask why on the highly connected internet is this needed? If one can get a fresh DocumentReference resource, why is it felt that the URL found in that DocumentReference can't be a fully qualified http GET resource/docment?
I'm not sure this is directed at me/us, but the issue we have with the url datatype in the reference to the content is that our current interoperability architecture in Sweden uses a more abstract concept that gets looked up in another stage of the interaction sequence and thus a url would not work.
If DocumentReference is not suitable for our use case, which seems to be the conclusions after some discussions in this thread, then by all means, url works splendidly.
Viktor Jernelöv (Dec 02 2019 at 16:23):
Yes, that is why I think that there is a new Resource type. It is not DocumentReference, and it is not Patient. It certainly should leverage CapabilityStatement, and it should not take the place of normal query of a given endpoint. Not clear what kind of a service this is, it doesn't feel purely REST. Today these services get an HL7 v2 ADT feed that is used to learn centerally where data might be for any given patient. Is this the right model in FHIR? Might this service be simply a routing hub that starts inefficient for any given patient (broadcast), but based on returned results becomes more refined for that patient?
**But without this kind of a record location service, clients are forced to probe all possible FHIR endpoints (or the user must pick and choose) -- this is not scale... and even knowing all possible endpoints is not clear how that is done...
And the system must be secure and privacy protecting...**
This right here is one of the main underlying problems we need to somehow handle in a Swedish context. My firm belief is that an 'RLS Profile' using FHIR would be long-term benificial for vendors and us working with national interoperability in other organisations.
Grahame Grieve (Dec 02 2019 at 17:35):
it's not clear what does solve this then?
Last updated: Apr 12 2022 at 19:14 UTC
