Where is the appropriate place in the FHIR model for encounter-related charges (professional or facility)?
Should these be stored:
as an extension within the Encounter resource?
in the Claim resource
somewhere else altogether?
In a future release of FHIR, we'll be introducing a "BillableItem" or similarly named resource that will capture the details of a specific charge or set of charges associated with an activity. It will be able to link to an encounter, patient and/or account. Unfortunately, there's been a limit to how many new resources the Financial Management work group has been able to develop given the bandwidth of their membership. In the interim, you'll need to make use of the Other (DSTU1) or Basic (DSTU2) resource if you want to stay within the schema and be technically compliant or create your own custom resource (if you're willing to be non-compliant). We'd certainly invite you to contribute back whatever you develop.
Alternatively, you may be able to get by in the interim with an extension. You can stick the extension where-ever you wish because it should be an interim solution until the appropriate work is developed.
Related
I've worked at companies where an admin role is able to select and view another user's private data (view the system as if through another user's eyes). In today's day and age, is this good, ethical practice?
Generally yes. An admin is typically representing the data controller directly (and may even be employed by them), and access to their data is often both useful and necessary as part of the service they are providing. Data processors (third parties acting on behalf of the data controller) in that role are subject to a data processing agreement that will usually include confidentiality requirements – this is something I do quite often.
That said, there are scenarios where you may be handling "special category" data (to use GDPR terminology), such as medical records, where you may need to be stricter about access and processing, and you might want to make use of security measures such as encryption of data at rest - admins in that situation can control exactly what the database server does, but may not be able to see what the data contains (for example using the encryption mechanisms provided by CipherSweet).
In special category situations, GDPR requires that you conduct a data protection impact assessment (DPIA) and/or a privacy impact assessment (PIA) before implementing solutions, so that you you are able to justify your decisions should an information commissioner ask for it. These sound onerous, but they are actually an interesting exercise, helping you introspect about your internal practices more objectively. Take a look at the excellent open-source PIA tool published by the French information commissioner, CNIL, to help you build these.
So in short, it's generally OK, but there may be cases where you don't want to allow it, or only allow it when using additional security measures.
While trying to understand how an existing system will map to FHIR resources, I am stuck in the documentation on Treatment/Care Preferences like the ones outlined here: http://wiki.hl7.org/index.php?title=Care_Preference
Would these preferences be handled in a list of extended objects? Or will FHIR be implementing a CarePreference resource?
This isn't catered for in the current set of resources. I guess you use Other (http://hl7.org/implement/standards/fhir/other.htm). It does seem like the kind of thing we'd want to define a resource for, but I'm not aware of any plans for one right now. I forwarded the suggestion along to the appropriate team.
btw, I'm not sure this question meets Stack Overflows guidelines - it might get edited/closed.
"Other" is the solution for now. Speed of the development of a specific resource is likely to be dependent on the number asking for it and the detail of the use-cases they supply. Consider sharing these on the FHIR list server. Alerts might be another mechanism to flag important preferences.
So I've built an iOS app (my first) and I want to distribute it for free. It's a content creation app, and my plan is to allow the user full access to record up to 5 records of content for the purpose of evaluation. If the user likes the app and wants to continue generating new content, he'll have to purchase an unlock via in-app-purchase.
I've looked at the documentation, and I'm going to use MKStoreKit to do this. I understand that I'm going to be creating a non-consumable, non-subscription product to sell.
So my problem is that while I can find lots of information on HOW to do the actual IAP, I can't find anything on where or how to track that it was purchased. That is, how do I go about ensuring the app is unlocked? Does it require a round trip to the AppStore servers on every app startup? If this is the case, I'm a bit concerned about it because network connectivity is not a guarantee.
Another possibility I've been thinking about is writing some kind of semaphore somewhere when unlock is purchased, whether it's a file or just modifying a setting in a .plist. This is certainly optimal from a user-experience point of view, but can it be easily hacked? If I write a file, can a user just take that file and distribute it to whomever?
Is there some standard mechanism or methodology that's typically employed here?
Thanks for any assistance.
What I usually do is check with the Apple servers if the content is unlocked. If so, I change some attribute in a .plist and check it to unlock the content.
There are two common approaches to achieve that: The first is to check only if the attribute is not set (or with a specific value) and the other, more secure but, im my opinion, not the best, is to have a point in your app that everytime it is executed the Apple servers are verified again.
What you need to have in mind is that if your application is hacked, you can't do anything, but there is a great number of users (most of them) that don't care about hacks and not even Jailbreaks... so forget it and apply the check when the app opens and only if it is not unlocked yet.
The original post was posted at https://stackoverflow.com/questions/6007097/design-question-for-notification-system
Here is more clarification of the problem: The notification system purpose is to get user notified (via email for now) when content of the site has changed or updated, or new posting is made. This could be treated as a notification system where people define a rule or keyword for 3rd party site and notification system goes out crawle 3rd party site and crate search inverted indexes. Then a new link or document show up for user defined keyword or rule (more explanation at bottom regarding use case),
For clarified used case: Let suppose I am craigslist user and looking for used vehicle. I define a rule “Honda accord”, “year “ 1996 and price range from “$2000 to $3000”.
For above use case to work what is best approach and how can I leverage on open source technology such as Apache Lucent, Apache Solr and Apache Nutch, and Apache Hadoop to solve this use case.
You can thing of building search engine and with rule and keyword notification system. I just need some pointers and help on how to integrate these open source package to solve use case ?
Any help and pointer will be appreciated. We need three important components are :
1) Web Crawler
2) Index Creator
3) Rule or keyword Mather
Any help will be greatly appreciated. I was referring this wiki which integrates Nutch and Solr together for above purpose http://wiki.apache.org/nutch/RunningNutchAndSolr
Your question is a big one but I'll take a stab at it as I've designed and implemented systems like this before.
Ignoring user account management, your system will need to provide the means to:
retrieve new prospect data (web spider)
identify and extract pertinent results from prospect data (filtering)
collect, maintain and organize results (storage)
select results based on various metadata (querying)
format results for delivery to users (templating)
deliver formatted results to users (delivery)
If the scope of your project is small (say less than 100 sites requiring spidering per day), you could probably get along with one of the many open-source web spiders including wget, Nutch, WebSphinx, etc. You might need to provide instrumentation (custom software) for scheduling, monitoring and control. If your project scope is larger than this, you may need to "roll your own" spidering solution (custom software). Typically this would be designed as a distributed, parallel architecture.
For simple filtering, regular expressions would suffice but for more complex tasks requiring knowledge of HTML layout (extract the textual component of the fifth list element (<LI/>) of the fourth table on the page) you'd need to use an XHTML parser. However you proceed, you'll need to provide custom software to conduct filtering based on your users' needs.
While any database technology can be used to store results extracted from retrieved documents, using an engine optimized for text like Apache SOLR will allow you to easily expand your search criteria as your needs dictate. Since SOLR supports the attachment of and search for metadata associated with each document, it would be a good choice. You'll also need to provide custom software here to automate this step.
Once you've selected a list of candidate results from SOLR, any scripting language could be used to template them into one or more emails and would also inject them into your mail transport agent (MTA). This also requires custom software to automate this process (and if required, to inject user-specific data into each message).
You should probably look at Google's Custom Search API also before diving into crawling the web yourself. This way, google can help you with returning keyword based search results, which you could later filter in your application based on your additional algorithms/rules etc, and make the whole thing work.
We are developing a web-application (lets call it an image bank) for which we have identified the following needs:
The application caters customers which consist of a set of users.
A new customer can be created dynamically and a customer manages it's users
Customers have different feature sets which can be changed dynamically
Customers can develop their own features and have them deployed.
The application is homogeneous and has a current version, but version lifting of customers can still be handled individually.
The application should be managed as a whole and customers share the resources which should be easy to scale.
Question: Should we build this on a standard OSGi framework or would we be better of using one of the emerging application frameworks (Virgo, Aries or upcoming OSGi standard)?
More background and some initial thoughts:
We're building a web-app which we envision will soon have hundreds of customers (companies) with hundreds of users each (employees), otherwise why bother ;). We want to make it modular hence OSGi. In the future customers themselves might develop and plugin components to their application so we need customer isolation. We also might want different customers to get different feature sets.
What's the "correct" way to provide different service implementations to different clients of an application when different clients share the same bundles?
We could use the app-server approach (we've looked at Virgo) and load each bundle once for each customer into their own "app". However it doesn't feel like embracing OSGi. We're not hosting a multitude of applications, 99% of the services will share the same impl. for all customers. Also we want to manage (configure, monitor etc.) the application as one.
Each service could be registered (properly configured) once for each customer along with some "customer-token" property. It's a bit messy and would have to be handled with an extender pattern or perhaps a ManagedServiceFactory? Also before registering a service for customer A one will need to acquire the A-version of each of it's dependencies.
The "current" customer will be known to each request and can be bound to the thread. It's a bit of a mess having to supply a customer-token each time you search for a service. It makes it hard to use component frameworks like blueprint. To get around the problem we could use service hooks to proxy each registered service type and let the proxy dispatch to the right instance according to current customer (thread).
Beginning our whole OSGi experience by implementing the workaround (hack?) above really feels like an indication we're on the wrong path. So what should we do? Go back to Virgo? Try something similar to what's outlined above? Something completely different?!
ps. Thanks for reading all the way down here! ;)
There are a couple of aspects to a solution:
First of all, you need to find a way to configure the different customers you have. Building a solution on top of ConfigurationAdmin makes sense here, because then you can leverage the existing OSGi standard as much as possible. The reason you might want to build something on top is that ConfigurationAdmin allows you to configure each individual service, but you might want to add a layer on top so you can more conveniently configure your whole application (the assembly of bundles) in one go. Such a configuration can then be translated into the individual configurations of the services.
Adding a property to services that have customer specific implementations makes a lot of sense. You can set them up using a ManagedServiceFactory, and the property makes it easy to lookup the service for the right customer using a filter. You can even define a fallback scenario where you either look for a customer specific service, or a generic one (because not all services will probably be customer specific). Since you need to explicitly add such filters to your dependencies, I'd recommend taking an existing dependency management solution and extending it for your specific use case so dependencies automatically add the right customer specific filters without you having to specify that by hand. I realize I might have to go into more detail here, just let me know...
The next question then is, how to keep track of the customer "context" within your application. Traditionally there are only a few options here, with a thread local context being the most used one. Binding threads to customers does tend to limit you in terms of implementation options though, as in general it probably means you have to prohibit developers from creating threads themselves, and it's hard to off-load certain tasks to pools of worker threads. It gets even worse if you ever decide to use Remote Services as that means you will completely loose the context.
So, for passing on the customer identification from one component to another, I personally prefer a solution where:
As soon as the request comes in (for example in your HTTP servlet) somehow determine the customer ID.
Explicitly pass on that ID down the chain of service dependencies.
Only use solutions like the use of thread locals within the borders of a single bundle, if for example you're using a third party library inside your bundle that needs this to keep track of the customer.
I've been thinking about this same issue (I think) for some time now, and would like your opinions on the following analogy.
Consider a series of web application where you provide access control using a single sign-on (SSO) infrastructure. The user authenticates once using the SSO-server, and - when a request comes in - the target web application asks the SSO server whether the user is (still) authenticated and determines itself if the user is authorized. The authorization information might also be provided by the SSO server as well.
Now think of your application bundles as mini-applications. Although they're not web applications, would it still not make sense to have some sort of SSO bundle using SSO techniques to do authentication and to provide authorization information? Every application bundle would have to be developed or configured to use the SSO bundle to validate the authentication (SSO token), and validate authorization by asking the SSO bundle if the user is allowed to access this application bundle.
The SSO bundle maintains some sort of session repository, and also provides user properties, e.g. information to identify the data repository (of some sort) of this user. This way you also wouldn't pass trough a (meaningful) "customer service token", but rather a cryptic SSO-token that is supplied and managed by the SSO bundle.
Please not that Virgo is an OSGi container based on Equinox, so if you don't want to use some Virgo-specific feature, you don't have to. However, you'll get lots of benefits if you do use Virgo, even for a basic OSGi application. It sounds, though, like you want web support, which comes out of the box with Virgo web server and will save you the trouble of cobbling it together yourself.
Full disclosure: I lead the Virgo project.